[Biococoa-dev] More on CoreData

[Koen van der Drift]

Hi,

I read the article, and it looks like a cool new feature to me. Not 
sure yet how useful it will be to BioCocoa. I think it will be more 
beneficial for developers who use BioCocoa for their own app and want 
to save datastructures. Although we do have IO classes, they are bound 
by the various sequence formats that are available. Other than taking 
over the accessors right now I don't see much more advantages. Of 
course, I don't have a seed, so you guys who have Tiger previews might 
know more about this than I do ;-)

However, if we decide to implement it, which is fine with me, than we 
should try to find a way that we at least keep supporting 10.3.x. The 
jump from 10.2.8 to 10.4 seems alittle bit too big. Also as you said, 
there will be ampel discussion in the cocoadev mailing lists on how to 
use existing datastructures with an NSManagedObject. I would say let's 
wait what comes out of that after the Tiger has been released.

cheers,

- Koen.

On Apr 6, 2005, at 1:27 PM, John Timmer wrote:

> In case anyone missed it, Apple finally put the overview article on 
> CoreData
> up:
> http://developer.apple.com/macosx/tiger/coredata.html
>
> This finally allows me the liberty of making a few more comments on the
> problems we'll have supporting both this and earlier OS versions at 
> the same
> time.
>
> The first is that all the objects that go into a CoreData store have 
> to be
> subclasses of NSManagedObject.  This class isn't going to exist in any
> previous versions of the OS.
>
> The second is that many of the classes we rely on (ie - NSArrays) 
> aren't
> native CoreData objects.  This means that, in order to stick an array 
> into
> an NSManagedObject subclass in a saveable manner, we'd have to first 
> convert
> it to data via NSCoding, or use its string representation.
>
>
> There's three ways I can imagine handling things:
>
> Create a "dummy" NSManagedObject subclass that's used to prevent 
> compiler
> errors when built on < 10.4.  This seems like an awkward solution, but 
> would
> allow us to start building CoreData compatibility into the basic 
> classes,
> like Symbols and Sequences.  Since the class won't actually be 
> NSManaged
> object, we can override some methods in our subclasses without 
> worrying that
> they'll ever be called on earlier OS versions.
>
> Create a separate framework that allows conversion between our standard
> classes and CoreData compatible ones.  This would at least allow a
> collection of BioCocoa objects to be shuffled into and out of a 
> CoreData
> persistent store, but wouldn't allow the use of some of the more 
> advanced
> CoreData features, like relationships, etc. in our classes.
>
> Give up and make BioCocoa 10.4 only, or at least provide a 10.4 only 
> fork.
> That's clearly the best from the feature perspective, but will clearly 
> limit
> our audience.
>
>
> There may be other options, and once the NDA comes off, I'm sure the
> Cocoa-dev mailing list will be full of people looking for (and 
> hopefully
> creating) solutions to similar problems.
>
> Anyway, I thought you guys would be interested (I could tell by Alex's 
> email
> to Apple that he is ;), and it's always better to start major design
> discussions sooner rather than later.
>
> John
>
> _______________________________________________
> This mind intentionally left blank
>
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>