MulleEOF today went from alpha state to beta state, which to me means, there are no features left to code. There are a few areas, where I know it's going to need some bug fixing and there are of course the bugs that will turn up over the next testing period, that I don't know of. But from my perspective it looks pretty solid already. Not that I don't have about a hundred different ideas how to do it better, but that is for the next version.
As noted before I sometimes update the site Project Titmouse with progress on the project. For the following monologue it would be helpful to look at Structure and Progress for an idea how MulleEOF is structured. Coz thats what I want to talk about first.
The original EOF had two frameworks EOControl and EOAccess. You couldn't use EOAccess without EOControl and I didn't like that, because sometimes it is just nice to use adaptor classes and the model to access a database and not have the whole EOEditingContext baggage with you. On that level EOAccess only uses EOControl minimally, and I set out to make that clearer by separating EOAccess and EOControl into little sub-frameworks. That is just like the Cocoa framework, which pulls together AppKit and Foundation, MulleEOControl and MulleEOAccess pull together their sub-frameworks for a familiar framework interfacing.
So on the Structure and Progress you see the dependencies of the various frameworks. These are #import and linking dependencies. For example MulleEOClassDescription is dependent on MulleEOFoundation, it imports MulleEOFoundation.h and links against MulleEOFoundation.framework. It does not link against MulleEOObserver, which contains basically all the [self willChange] mechanics and therefore it also does not include any of its headers. You may think, not such a big deal... but just by looking at it you will know, that EOClassDescription (in its non augmented form, non augmented ? more about this later) is for instance not calling willChange. Or a more useful example as incidentally EOFetchSpecification is defined in MulleEOFoundation you know that contrary to original EOF, calling -[EOFetchSpecification setQualifier:] will not result in a [self willChange] call. If you know the frameworks and their dependencies, you have more of a clue what is going on, then you probably used to.
If we'd take a look at EOFetchSpecification in MulleEOFoundation you'd probably be a little shocked to find that +[EOFetchSpecification fetchSpecificationWithEntityName:...:] and -[EOFetchSpecification initWithEntityName:qualifier:...:] are missing from the header. And they aren't in the .m file either! Instead you find a definition like +[EOFetchSpecification fetchSpecificationWithClass:qualifier:sortOrderings:] and you think, hey and this is supposed to be EOF compatible ?
And that's where the augmentation style programming comes in.
MulleEOFoundation contains a variety of classes like EOQualifier, EOSortOrdering and EOFetchSpecification; classes that do some useful operations on basic foundation objects. The only prerequisite of the foundation objects are, that they are key-value coding compliant. There is no concept of objects being stored in a database or managed by an EOEditingContext. So if you only link to MulleEOFoundation, you know what to expect.
Now EOFetchSpecification is a useful but not very clever class, that ties EOQualifier and EOSortOrdering together. Its class parameter (in MulleEOFoundation) acts like an additional qualifier, to filter objects that satisfy class or subclass membership.
But the methods with entityName are of course needed. And here the first question should be: What is the entityName ? What is an entity ?
The entityName at the level of EOControl (and this means original EOF and MulleEOF) is some sort of object provider thingamajig. If we use EOAccess, we know its the name of an EOEntity, but EOAccess is not a necessary component for EOControl. You can write an application using EOControl and have a custom kind of EOObjectStore subclass and that EOObjectStore subclass has to deal with entityName and do something with it. So all we can really say about entityName is, that it restricts object stores in some fashion to the objects it will provide. Because the concept of "some abstract entity that provides us with objects", is pretty far removed from the mundane tasks of MulleEOFoundation, it appeared to be warranted to give it its own framework.
Well I'll stop here for now. I haven't even gotten halfway...