[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RES: RES: Standard Object Reflection (was Re: OOP in daydream...)
- From: André de Leiradella <leiradella@...>
- Date: Thu, 20 Jan 2005 00:46:40 -0300
>> . Multiple constructors can be defined
> Why have "constructors" in the first place? What about a class methods
> instead? E.g. anInstance = MyObject:class:new() or such.
In one of my class systems I had to "call" the class to get an instance
screen = Screen(640, 480)
But it allows for only one constructor. The concept of constructor,
although they're just functions at the end, is important because it's
inside the constructor that the new instance is created, and when that
happens you have a lot of housekeeping to do that you don't want to
write in every classes' constructors...
>> Having super_of returning an iterator gives the programmer the
>> choice of having multiple inheritance or not, I do have in my class
>> system to mimic Java's interfaces.
> What about forgetting about multiple inheritance all together and
> instead just allow for "behaviors" to be moved around (something along
> the lines of AOP)? So you could say something like:
> MyObject:class:addImplementation( anotherClass )?
I don't know what behaviors are, could you elaborate?
> You could as well support the equivalent of Objective-C categories by
> providing a function to adds methods to any classes as well: e.g.
> MyObject:class:addMethod( aMethod ).
Things are getting complicated :)
>> . The syntax to call inherited methods
> What about something like: anInstance:super:doIt()?
I think that can work, when a method is looked in a class, it's the
class' responsibility to return it, looking to it's ancestors if
necessary. But I like sugar so I'll wait for lhf's token filter.
Andre de Leiradella