Collection Object

[Philip Mötteli]

Am 01.08.2006 um 16:10 schrieb Ruslan Zasukhin:

> On 8/1/06 2:10 PM, "Philip Mötteli" <philip.moetteli at econophone.ch>  
> wrote:
>
>> I have another proposition how we could approach the problem (instead
>> of looking how Postgres possibly does it): Lets assume the following
>> M:M intermediate table:
>>
>> MMIntermediate
>> {
>>    collectionRecord as ObjectsPtr,
>>    nextRecord as RecID,
>>    memberRecord as ObjectsPtr
>> }
>
>>       ..........    PICTURE ...............
>
>
>> (For the moment just ignore the 'nextRecord', which is there only to
>> create an ordered collection).
>
> okay
>
>> So this MMIntermediate table would play the M:M table, joining the
>> collection table (e. g. NSSet) to the destination table of the member
>> object (here displayed by taking the root of all Foundation objects:
>> NSObject).
>
>> This would replace the array kind of field, proposed by
>> Postgres and Ruslan.
>
>> How would searching work in this case? I mean, here too, I can search
>> for a field of the member record, that possibly doesn't exist?
>
> Philip! :-)
>
> And here you have describe nothing else as solution based on  
> inheritance
> which I also have show 1-2 days ago. Please find my letter.
>
> * We have some ROOT table  == NSObject
>
> * Tables T1 T2 T3 are inherited from this table.

What do they inherit?


> the biggest news for me is this kind of search by attribute
> which can be absent in a table. This is very unusual for Relational  
> model,
> and I have not see such kind of search even in ODMG. It seems to be
> invention of Apple.
> Again, technically it is possible for DBMS also.
> Problem is to developer new set of API

It is your invention too. You have already prepared such a kind of  
search, when you introduced ObjectPtrs. Just look at the example with  
the MMIntermediate table. There's no new element in that example. So  
the question about such a type of search should already have been  
risen, when you introduced ObjectsPtr. You just have to remember,  
what you thought back then.


> Next, I think this is the most correct direction to think about.
> It is simply mirror objects that you have in NS...

:-)	My pleasure!


> I am more used to C++.

No problem. Here I can help.


> 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.
It's not the collection, that cares about the type/inheritance of a  
member. It's the ObjC runtime system.
In ObjC, we have a generic type: id, which is actually just a pointer  
to the very basic skeleton, that every object has:

typedef struct objc_object {
	Class isa;
} *id;

typedef struct objc_class *Class;

struct objc_class {			
	struct objc_class *isa;	
	struct objc_class *super_class;	
	const char *name;		
	long version;
	long info;
	long instance_size;
	struct objc_ivar_list *ivars;
	struct objc_method_list **methodLists;
	struct objc_cache *cache;
  	struct objc_protocol_list *protocols;
};


The compiler creates for every method call of some object the  
following function call:

	objc_msg_send(someObject, method,…);

This function then looks up the concrete method using

	someObject->isa->methodLists

populates it with the arguments, by reading out its signature.

In order to do all that, the compiler has to pack a lot of runtime  
information about the objects and their methods into the program. And  
it is exactly that runtime information, that also allows me to write  
my transparent persistence layer.
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).


> It sounds that in Objective-C you can do more flexible things...

Much more. I'm using this capability also for faults and proxies in  
my persistence layer.


> Send to NSObject some query/event which it can have and may be no.
> Right?

Any object, exactly.


> In C++ I also can simulate this behavior easy, just defining in  
> parent class
> method like DoEvent( EVENT* e ). C++ do not care what is inside of  
> EVENT

I imagine, that this is something like NSInvocation (<http:// 
developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/ 
NSInvocation_Class/Reference/Reference.html>)?


> It is possible of course invent build some mechanism for db also...
> But it is not first step.

I think it is better like this:

if(table(Table_ID)->hasField('name'))
	doQuery…

Is the better approach.


Re
Phil