Collection Object

[Philip Mötteli]

Am 04.08.2006 um 22:10 schrieb Ruslan Zasukhin:
> On 8/1/06 6:37 PM, "Philip Mötteli" <philip.moetteli at econophone.ch>  
> wrote:
>
>>> In C++ when I have container of Some objects casted to Parent class,
>>> I can access methods and attributes only of parent classes. You
>>> remember
>>> this yes?
>>
>> No, but I know, that C++ does a lot of tinkering in order to be OO.
>
>> Aha, that's the reason, why you constantly link inheritance with
>> collections.
>
> :-) right.
>
> Well, this is not just C++ issue.
> I am sure that REALbasic, Java, C#, work in the same way.

Yes, a lot of object-orientedness is still missing in those  
languages. And no surprise, that in the prototype of all OO  
languages, Smalltalk, it works like in ObjC.
But only because those languages are not on the top, doesn't mean,  
that your implementation of "method dispatching" in Valentina must  
carry on the same restrictions, does it? No you could say, my  
implementation does it right from the beginning on – like Smalltalk.


>> To cut a long story short: A collection object doesn't need
>> inheritance. It only needs a format constant member indication and
>> dynamic binding (that is the dynamic dispatching of these methods).
>
> Well, I can say this is just the maximal generalization of idea.

No, this is object-orientedness. A language, that doesn't offer this  
doesn't fulfill the requirement of OO. Polymorphing has never been  
defined as being restricted to subclasses because a method has to be  
defined at compile time.


> 1)  Collection of the same types -- e.g. arrays in C
>
> 2) Collection of objects of different type but with the same PARENT  
> class,
>     we have this in C++ C# Java, RB, ...
>
> 3) ObjC have made step future

No, those other languages made a step backwards. This behavior is  
part of OO and was already available in Smalltalk.


> Payment for this is that EACH class is RTTI class, and each
> its method is virtual, and even worse than virtual.

That's the big reproach people always say. And that's exactly the  
language flame war, that I didn't want to start with you.


>> I think it is better like this:
>>
>> if(table(Table_ID)->hasField('name'))
>> doQuery…
>>
>> Is the better approach.
>
> I have think exactly about the same thing, Philip :-)
>
>
> start:
>
> * We take Oid,
>
> * go to record pointed by it:
>     this bring us to some table T
>     we ask this table if it have field we need
>         if yes - do search there
>         if no - go to start

Anyway, speed is not my priority for a long time. Once we will be  
familiar with this new feature, we can further improve the speed of  
its implementation (if needed).


Re
Phil