NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/next/programm/6103

Text File | 1992-09-10 | 3.4 KB | 68 lines

Newsgroups: comp.sys.next.programmer
Path: sparky!uunet!psinntp!spunky!glitter.RedBrick.COM!jfr
From: [e-mail] ()
Subject: Re: Multiple init: functions defined
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: glitter.redbrick.com
Organization: Red Brick Systems, Los Gatos, CA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 10 Sep 1992 03:40:58 GMT
Lines: 55

In article <[e-mail]> [e-mail] (Alex Blakemore) writes:
>In article <[e-mail]> [e-mail] writes:> In artic
>> A selector name, like a C function, should only have one set of
>> argument types. [Think about it: you wouldn't write two C functions with
>> the same name, but different arguments, even if they were static to the
>> module in which they appeared. Well, you might, but you couldn't get a job
>> with my firm. 8^)]
>
>actually having several functions share a single name can be very useful.
>Its called overloading of course and exists in languages like Ada and C++.
>
>As long as the compiler can resolve the reference to the correct call,
>and you only overload semantically similar operations, it can be a great convenience.

  I agree that this can be convenient, but it is also a potential
  source of problems.  In C++, overloading is almost mandatory to
  support initializers, but in other cases, it is generally only
  a cosmetic.

>There's no need to remember half a dozen names for the same conceptual operation.
>you could then use just setValue: instead of setStringValue:, setIntValue:,
>setFloatValue: etc - the compiler can figure out which one you meant from the
>argument type and you can worry about other things.  Its convenient for some
>of the same reasons that polymorphism is.

  I used to believe this too.  After thinking about it some more, I realized
  that the problem is NOT really with the issue of overloading, but with the
  fact that the base C datatypes are not first-class objects in Obj-C.
  Thus I can easily create a single method called setObjectValue:(id)x
  which will take an anonymous object and do internally correct things
  to set the value based on x's class.  This is not possible with regular
  C datatypes, however, since they carry no object identification.  In
  Smalltalk, since all datatypes are classes and everything is an object,
  overloading is implicit since any object can be passed as any parameter
  to any method, as long as the method can deal with that type of object.
  C++ is a compile-time language where overloading makes some sense (and
  is sort of required).  Smalltalk is a run-time language where objects
  can (and should) be dynamically typed, not dealt with by a compiler.
  Obj-C sits on the fence, and while I much prefer it to C++, I still
  feel it has some shortcomings.

>The AppKit would be a lot simpler to learn if Obj C allowed overloading IMHO.
>
>of course it can be abused and lead to confusion - like most powerful features.
>
>I once saw someone spend hours trying to figure out why he got a division by zero
>error on a line that did not contain any division operators.  It turned out he
>had redefined the operators to get a particular form of unit conversion (fine)
>and had cut and pasted the division routine into the multiplication routine.

  This is one of the problems with overloading.
  It is, of course, also a problem with sloppy programming :-)

  Jon Rosen