dougw@grebyn.com (Doug Worthington) (02/05/91)
Currently I am developing on a Next and have the following scenario
and problem. I have defined a series of objects for use with
databases. I have an abstract superclass named field that will
manager things similar to all fields like name, width and maybe some
more information. More specific types of fields are strings, ints
floats etc. Currently a series of routines allocate the objects based
on the types of database columns requested and returns a charfield,
intfield etc.
My problem is this. I want the user to get and set these
fields with the same routine names getValue and setValue without
having to cast the value as an char *, int etc. When the user
includes the interface files with the program the compiler is confused
with the names complaining that there are more then one get/setValues.
Which there are, one for each type of field with a different
return/parameter type. This lack of overloading is a bummer. I
realize I am a bit braindead on this problem but why can't the
compiler do some scoping of the arguements and determine which method
to call.
Thanks
Doug Worthington
dougw@grebyn.com
localhost 12>tomnews%apgraph@ap542.UUCP (Thomas Oeser (SNI AP 153)) (02/07/91)
In article <25258@grebyn.com>, dougw@grebyn.com (Doug Worthington) writes: |> |> *** stuff deleted *** |> |> My problem is this. I want the user to get and set these |> fields with the same routine names getValue and setValue without |> having to cast the value as an char *, int etc. When the user |> includes the interface files with the program the compiler is confused |> with the names complaining that there are more then one get/setValues. |> Which there are, one for each type of field with a different |> return/parameter type. This lack of overloading is a bummer. I |> realize I am a bit braindead on this problem but why can't the |> compiler do some scoping of the arguements and determine which method |> to call. The best (on also object oriented!) way to solve this problem is to use OBJECTS as parameters of getValue() and setValue(). Having, a proper superclass, amy subclass will fit... Thomas Oeser ****** DISCLAIMER: All opinions stated here are strictly my own ********* ------------------------------------------------------------------------- Internet: thomas%apgraph%ap542@ztivax.siemens.com Europe: thomas%apgraph%ap542@ztivax.UUCP Phone: + 49 89 636 47537 Fax: + 49 89 636 45522 Postal Mail: Siemens Nixdorf Information Systems AG, AP 153, Carl-Wery-Str. 22, D-8000 Munich 83, West Germany -------------------------------------------------------------------------
lerman@stpstn.UUCP (Ken Lerman) (02/11/91)
In article <25258@grebyn.com> dougw@grebyn.com (Doug Worthington) writes: ... > > My problem is this. I want the user to get and set these >fields with the same routine names getValue and setValue without >having to cast the value as an char *, int etc. When the user >includes the interface files with the program the compiler is confused >with the names complaining that there are more then one get/setValues. >Which there are, one for each type of field with a different >return/parameter type. This lack of overloading is a bummer. I >realize I am a bit braindead on this problem but why can't the >compiler do some scoping of the arguements and determine which method >to call. > >Thanks > >Doug Worthington > >dougw@grebyn.com >localhost 12> If class Foo defines: -(char *)getValue; and class Bar defines: -(double)getValue; Then we can write: Foo *aFoo; Bar *aBar; aCharStar = [aFoo getValue]; aDouble = [aBar getValue]; and the compiler will disambiguate the two cases. NOTE that you MUST know the type of the receiver because the left hand size must be of the proper type. We could even write: id alpha, beta; aCharStar = [(Foo *)alpha aSelector]; aDouble = [(Bar *)beta aSelector]; The selection of which declaration of the selector to use is determined by the class of the receiver if the class can be determined. The user must (obviously) know which he was using because he had to assign to the proper type (char *, or double). The same is true if there are arguments of differing types as in: -setValue:(char *)arg; // in class Foo and -setValue:(double)arg; // in class Bar Ken