jute <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >
> >   There are basically three requirements for an OOP language:
> >
> > 1) Modules.

> #include, like you pointed out.

  A module is something which you can instantiate. You can thus have
several instances of the same module, each with their own state. You
can even make these instances refer to other instances of the same
module (to create, for example, linked lists).

  An #include file is a really, really ascetic "module" which has only
one single static "instance" and that's it. You can't make several
instances of it and you can't have every instance have their own state.
It can hardly be called a module at all.

  In object-oriented programming modules become extra important because
of inheritance: You can make modules which are inherited from other
modules, and you can make functions which handle base type modules and
give then derived type instances instead, and it will work ok. You can,
for example, have a linked list where each node is of a different type
(but inherited from a common base module).

> > 2) Inheritance.

> now w/  operator overloading!

> #declare Sphere = sphere { <0,0,0>, 1 pigment { rgb 1 } }
> #declare Sphere_Child = sphere { Sphere pigment  { rgb 0 } }

  That isn't even valid syntax. You probably meant "object { Sphere ...".
And even then it doesn't work: The second object will be white too.

  And even if it did work as you wanted, it would still not be inheritance.
What you are doing there is making a copy of an object and modifying (or
trying to, if POV-Ray supported it) its attributes. That's not inheritance.
The first sphere is not a more abstract object and the second one a more
specialized one. IOW, there's no "is a" relationship. There's more like
an "attributes were copied from" relationship.

> > 3) Dynamic binding.

> Well, gosh.

  Inheritance is quite pointless without dynamic binding.

  Ok, it can be used to group common functionality and contents into
one base class, but that's about it. You can't specialize anything
in the inherited classes in such way that the specializations will
be called even in code which only handles base class type references.

-- 
                                                          - Warp

Post a reply to this message