Re: Name Space conflicts and Swarm?

[Ken Cline]

On Wed, 2 Jun 1999, Marcus G. Daniels wrote:

> >>>>> "PJ" == Paul Johnson <address@hidden> writes:
> 
> In the grammar..
> 
> http://developer.apple.com/techpubs/macosxserver/System/Documentation/Developer/YellowBox/TasksAndConcepts/ObjectiveC/grammar.htm
> 
> compare grammar.htm#724, and #740-2.
> 
> PJ> I've run into it with methods
> PJ> like "getPosition" and "getCount" as well.  I've fixed this by
> PJ> just renaming my methods so they don't have the same names as
> PJ> methods in the swarm library.
> 
> PJ> But I don't understand why it happens.  If on the inheritance tree
> PJ> there is a class with a method getStatus, my new method ought to
> PJ> override it.  If there's a method by that name in another class,
> PJ> why does the problem arise at all?
> 
> Objective C isn't polymorphic.  If you want to override a method,
> the argument and return types all should match up.

Adding a little more to this...
(You've probably seen this, but its easy to miss.)

>From the apple manual mentioned above:

  HOW MESSAGING WORKS
      [snip]
    Methods and Selectors

    Compiled selectors identify method names, not method
    implementations. ... This [...] lets you send the same
    message to receivers belonging to different classes. If
    there were one selector per method implementation, a
    message would be no different than a function call.
      [snip]

    Method Return and Argument Types

    The messaging routine has access to method implementations
    only through selectors, so it treats all methods with
    the same selector alike. It discovers the return type of
    a method, and the data types of its arguments, from the
    selector. Therefore, except for messages sent to
    statically typed receivers, dynamic binding requires all
    implementations of identically named methods to have the
    same return type and the same argument types.
    (Statically typed receivers are an exception to this
    rule, since the compiler can learn about the method
    implementation from the class type.)
      ...

I hope this clarifies a little more why the compiler warns
you when there are 2 or more methods with same name but
different argument or return types.  And, as it suggests,
you can quiet those warnings by casting the receiver to a
particular type.  For example, my agents have a
`getPosition' method that returns a Point object.  If I
don't want to see the compiler warnings, then I just do
something like:
  id <Point> p = [ (id <SpatialAgent>)agent getPosition ];

Of course, now the receiver is statically typed and if (for
some reason at runtime) the receiver does not conform to the
SpatialAgent protocol then bad things can happen. (Actually,
I've never tried to see what would happen.)

It is perhaps just as easy to rename the method (as you did) 
and I usually try to make the name more descriptive and
hence less likely to cause a naming conflict.  In the example
above, I might suggest calling the method `getSpatialPosition'
instead of something like `getLocation'.  (Its a personal
preference, of course.)

BTW, other OO languages (e.g. C++ and Java) allow you to
have multiple methods (within the same name space) that have
the same name but different argument and return types.  This
is because, in those languages, methods are identified by
their signature which includes all that information (i.e.
the method name, argument types and order, and the return
type); this is sometimes called "function overloading".

This is also why in the Java reflection api you can not
lookup a method by only its name; you must also specify the
argument types.  In Objective-C, this isn't necessary, e.g.
  [actions createActionTo: bug message: @selector(jump:):arg]
or, in Swarm parlance:
  [actions createActionTo: bug message: M(jump:):arg]

Ooops!  I guess I drifted off topic a little.  My apologies
for sucking up valuable bandwidth by reprinting the manual
and restating a lot of stuff you probably already knew.

Happy ooping!

Ken.


_________________________________________________________
Ken Cline                             address@hidden
SAIC                                 VOICE (410) 571-0413
Annapolis, MD                          FAX (301) 261-8427



                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.