Protocols and OO-ness [was: Copy method]

[Juan J. Merelo]

>>>>> "glen" == "glen e p ropella" <address@hidden> writes:

    >> this. Protocols is the means by which Obj-C mimics multiple
    >> inheritance. Protocols are also not really OO, which may appeal
    >> to you as a solution (since you said OO was the problem).

 
    glen> learning curve), I'm probably not aware of the differences
    glen> between the OO-ness of protocols and any so-called classical
    glen> OO.  I'd assumed that inheritance was an OO concept, and,

I wouldn't say that protocols are not OO. One of the pillars of
OO-ness is separation of interface and implementation, and protocols
are the way of achieving that in Objective C. Indeed, it's a pretty
good practice to use something similar in C++: Abstract base classes,
which have no implementation, and which force any subclass to
reimplement those methods.

I guess that all this is somewhat lateral to the discussion, but I
couldn't help but jump in.

In any case, protocols are the only way of achieving multiple
inheritance in ObjC, if only with respect to interface, not
code. Which is probably wise, since code multiple inheritance causes
lots of problems in C++, anyways.

    glen> Now, there's no *real* problem with this.  However, there is
    glen> a model specification problem.  The universe is responsible
    glen> for initialization of bugs but not for the cloning of bugs.

It's not. Bugs are responsible for their own initialization, through
the proper method. What you are saying here is that constructors, or
factory methods, really belong to the universe.

    glen> message specified as "- (id) copy;".  Can a protocol do this
    glen> kind of mapping?  Or would it be necessary to create a
    glen> method in the universe object that took the former message
    glen> and reformulated it to send it to the bug argument?

Of course not, but a "Copiable" protocol could be created, objects
that follow it forced to implement it. 

This is not such a big deal in C++: copy ctors are compiler-generated,
if you don't bother to supply one; and they should be defined in any
well-behaved class. Besides, they are not inherited, which forces you
to supply a copy constructor, or copy method, everywhere in the
hierarchy.

                                JJ

-- 
address@hidden