[Nitro] Concerns over Og mandating the form of initialize
george.moschovitis at gmail.com
Thu Apr 14 03:30:07 EDT 2005
> The other issue is, what is being saved/retrieved: objects or data?
Objects are saved, but objects are ALLREADY intialized. You dont have
the object EVERY time you read the object from the database.
> This is an important issue, though. When a row is retrieved from a
> table, is it to restore a specific object, or to drive the creation of a
it restores a new object.
> new object? The later is not deserialization (to my mind), and leaves
> open the idea that the data may come from a variety of sources.
yeap, this is not deserialization, thats my point. Og does deserialization.
your idea is interesting though. But I guess if this other source follows
some convention it will work with the existing model.
> So, yes, with deserialization one should not be calling the constructor,
> but objecting to calling 'new' presumes that deserialization, rather
> than object creation, is the goal.
yeap deserialization is the goal, i think it makes sense :)
> a clear need for it. Having to rework the constructor, and add new
> methods that only make sense when used with Og, seems more burdensome.
:( I dont understand you. Og now uses klass.allocate, so Og is
indifferent to the constructor. you can have any constructor you want.
You dont have to make a 'special' constructor for Og.
> For what its worth, I'm somewhat skeptical of saving and restoring
> objects as objects, rather than creating new objects from saved data,
> because I think you end up trying to have a virtual object database that
> has to sit atop assorted relational databases.
yeap but the relational database is created automatically for you.
That thing aside,
I plan to add some form of 'reverse engineering' of existing schemas
in Og. This is very easy to do.
> On the other hand (of course), I'm intrigued by the idea of a framework that
> completely hides the notion of any relation database underpining; you just code as if all
> you have are objects, and saving restoring deals with specific objects,
> not relational data.
this is what Og tries to do.
BTW, I still have the feeling I dont understand your point correctly.
Perhaps we could better discuss this on IRC. How about freenode
More information about the Nitro-general