Warp wrote:

>   However, can this be called object-oriented? Having objects in an array
> excludes the possibility of using objects of a derived type (unless an
> object of the derived type has the exact same size as the base type object;
> even then it requires some low-levelish trickery to get it working, at
> least in C++, and probably other languages where objects can be handled
> by value and put into arrays). However, one of the basic ideas of OOP is
> that whenever an object of type A is expected, an object of type B can be
> given to it instead, if B has been derived from A (or from any of its
> subclasses). An array of objects wouldn't support this.

Wouldn't you just need to determine the storage requirements of THE 
LARGEST class of object? And allocate that amount for every object?

Granted, I don't actually know of a language or compiler which actually 
supports this...

(In particular, if you can add new subclasses dynamically at runtime, 
this approach obviously won't work at all. But if all classes are known 
at compile-time, it's feasible in principle.)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Wouldn't you just need to determine the storage requirements of THE 
> LARGEST class of object? And allocate that amount for every object?

  No, because indexing is done based on the type of the array. For the
indexing to work properly the array type would have to be that of the
largest object type, but then you wouldn't be able to easily store any
other type of objects there (because now you would be handling objects
of the most derived class type rather than objects of the base class
type).

  You could probably get around this limitation by creating an array
container class which handles the memory allocation and indexing using
low-level functionalities (raw pointer arithmetic and such), but it would
be quite a hack. And you wouldn't be able to use pointer arithmetic on
the array directly (except by using more abstract iterators).

  Then there's the problem of assigning objects: If you assign an object
to a place in the array where there's already an object, and they are of
different types... I don't think it would work. Maybe you could get around
it by first destroying the existing object and then placing the new object
in its place using placement new, but it becomes complicated.

  Perhaps not *impossible*, but as you may guess, quite hard and kludgey.

-- 
                                                          - Warp

Post a reply to this message

>> Wouldn't you just need to determine the storage requirements of THE 
>> LARGEST class of object? And allocate that amount for every object?
> 
>   No, because indexing is done based on the type of the array. For the
> indexing to work properly the array type would have to be that of the
> largest object type, but then you wouldn't be able to easily store any
> other type of objects there (because now you would be handling objects
> of the most derived class type rather than objects of the base class
> type).

You seem to be looking at "can you do this in an existing language?" I'm 
looking at "is it feasible for a hypothetical OO language to support 
this efficiently?" I think it could be supported efficiently; I just 
can't think of any language which does it.

>   Perhaps not *impossible*, but as you may guess, quite hard and kludgey.

Not if it's hard-wired into the language. Then it becomes no less hard 
or kludgey than (say) generating the illusion that each program on the 
machine has complete control of the entire machine, when in reality the 
OS is time-slicing them and sharing memory and I/O resources between them...

Post a reply to this message

Invisible wrote:
> One of the points of a relational database is that several programs can 
> use the data, possibly in ways not originally envisaged.

I'd go so far as to say that was the *primary* point. We already had 
standard database stuff using pointers, called CODASYL. It sucked if you 
wanted to do anything unexpected with it.

> Today, lots and lots of people seem to forget this. They think of a 
> database as being a system for holding data that only one application 
> uses and only that application understands. This isn't what a database 
> is supposed to be. It's supposed to facilitate access by multiple programs.

This si why I laugh at people who say it's better to put the data 
consistency assurances in the program.

> Or sometimes it's just for performance. An order can be completely 
> identified by the customer it's for, the date it was placed, and what 
> was ordered. 

Well, probably customer and timestamp. You don't have to know what they 
ordered at 14:01 on Jan 23 to find it. The artificial key, being artificial, 
is a secondary key, not a primary key.  Unless it is printed on the physical 
slip you used to take the order, like at a restaurant or something.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Warp wrote:
>   One interesting question: If objects are in an array rather than being
> individually allocated (and handled through references/pointers), can it
> still be called object-oriented?

I would think so. Inheritance is just one part of the OO thing.

 > An array of objects wouldn't support this.

It could, if you allocate enough space in the array for child types. Of 
course this breaks if you start loading new child classes at runtime. You 
just artificially inflate the size you allocate to be large enough.

You're also running into the covariance problem. If you have

virtual A* x(B*) { ... }

(i.e., a function x that take an instance of B or one of B's subclases as an 
argument, and returns an instance of class A or one of A's children...)

what is a subclass that overrides that x allowed to declare as a return type 
and an argument type?  Is it allowed to accept only C*, where C is a child 
of B?  Is it allowed to accept D*, where D is a parent of B?  Now ask the 
same about A, and you get a completely different answer.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Invisible wrote:
> I think it could be supported efficiently; I just 
> can't think of any language which does it.

C# lets you declare arrays of objects that are inline like C++, and the 
generic "List" class will generate special versions when you instantiate it 
with a class that is pass-by-value, but the nature of the pass-by-value 
objects is that you can't inherit from them and add any fields, so the 
question doesn't come up.

>>   Perhaps not *impossible*, but as you may guess, quite hard and kludgey.
> 
> Not if it's hard-wired into the language. 

Yeah. C++ style OO is kludgey in C. That's why cfront was written. :-)

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message