[Nitro] help with og!

zimba-tm zimba.tm at gmail.com
Fri Dec 23 22:10:25 EST 2005

I'm happy you took some time to review this idea.
On 24/12/05, TRANS <transfire at gmail.com> wrote:> I've finally was able to take some time to look it over. I have to say> it looks pretty sexy.>> The Setup I think is very nice, being both clean and explicit.
Ok, nice. I love to think simple.
> Relations is a very cool idea, although it may be a little _too_> magical. A couple of issues come to mind: what if you actually do want> to store a class in an attribute?
I see. Do you see any case where it would be useful to store classesdirectly ? In the actual Og, we have shema_inheritance, but it ismanaged by Og. So I assume it can be handled differently.
> Also what if it doesn't conform to> the pluralization rules?
If applicable, I had in the idea that the Og would replacerelationships with an Enumerable object. How could we tell thatGroup[1].users is an array of User ? Also, is it possible to havedifferent classes in the enumerable ?
class Group  def initialize()    @users = Array.of User  endend
> We need nice ways to handle these.
I totally agree. In general, I think we could use the ann tool torefine the objects. Maybe other ideas will come later.
> The Types idea seems like the right approach to me too, but it harder> than you might realize --I've tried it. You have to take into account> that it might differ for each DB-adapter, so that adds another> dimension.
Yes. What I like with the current Og is that an adapter doesn't haveto implement every transformation if it's compatible. What do youthink of re-opening the classes to inject adapter-specific code ? Wehave to take in account that it should also be possible to use twostores at the same time on different adapters. So we can't justreplace the main Og::Type code with adapter-specific code.
> (Hmm... that's insteresting, OT but, OOP is sort of two> dimensional in nature Object x Subject. It will be Selector Namespaces> that actually move us beyond this. Very interesting....) If we had> Selector Namespace though we could define the method according to> which adapter was in use --that would be pretty awesome.
I think your ruby OOP-fu is way beyond mine. What do you mean by"Subject" ? I think I get the idea, but I'm not sure at all. Talkingabout alternatives, what do you think of the "cut" AOP library ?
I just had a funny idea while re-reading this email. I think mostprototype-based languages are not successful because the differencebetween a class and an instance is too weak. People get lost in thecode structure. On the other side, class-based OOP languages arefighting to remove the difference between a class and an object (eg.meta-ruby). Do you see the contradiction ? :-p
--Cheers,  zimba

More information about the Nitro-general mailing list