Re-implementing Vs Overloading methods

[ConvertFromOldNGs]

by Kevin Alcock >> Mon, 24 Jan 2000 2:50:28 GMT

I'm not sure if this has been discussed before, but is it possible to overload method signatures?

Take the good old loadSelf example I want to use a standard method in my class hierarchy but extend the method each time I subclass it. Better still having parameters on the create method would be bliss. If its good enough for other OO languages such as C++ and Java, don't you think its good enough for Jade.

I would like to here from others on how they do this and how it changes their models from C++/Java to Jade.


Thanks,

Kevin

--
kalcock@cardinal.co.nz
Phone: +64 3 365 2266 x 3086
Cell: +64 21 638 586

[ConvertFromOldNGs]

by Torrie Moore >> Mon, 24 Jan 2000 4:51:17 GMT

Kevin

You can overload method signatures but you can only subclass the type of the parameters, not add new parameters etc. This would allow you to use a parameters object which can then be subclassed with more references, attributes allowing more information to be passed. I imagine this would be a little messy to implement though.

About the parameters for the create methods. We have out own create methods that we use to create object. These methods take parameters, create the object and then set the properties etc and return the object created. It is not possible to add parameters to the create method in Jade but this serves just as well.

eg
createCustomer(org : Organisation; name : String) : Customer
vars
customer : Customer;begin

create customer;
customer.setOrganisation(org);
customer.setName(name);
return customer;
end;

Hope this helps

Torrie Moore (Mr )
torrie@concept-eng.co.nz

[ConvertFromOldNGs]

by Eric Peachey >> Mon, 24 Jan 2000 21:04:02 GMT

...is it possible to
overload method signatures?

Take the good old loadSelf example I want to use a standard method in my class hierarchy but extend the method each time I subclass it. Better still having parameters on the create method would be bliss. If its good enough for other OO languages such as C++ and Java, don't you think its good enough for Jade.

There's a whole load of arguments for doing such things in a similar style to JADE. Have a read of Object Oriented Software Construction (Second Edition) by Meyer. He gives lots of reasons why you shouldn't have methods with the same names differentiated by parameters. C++ etc also allow the same name to be used more than once in the same class using different parameters.

Basically, if methods do different things shouldn't they have different names?

On creation procedures: I don't think the way C++ creation procedures are defined is superior to JADE in anyway. It's not a big deal to create an object and then call a method on that object.

Eric in Dunedin where it's Winter all year

[ConvertFromOldNGs]

by Carl Ranson >> Mon, 24 Jan 2000 23:10:17 GMT

It depends of the semantics of the method. In the cases where it's doing the same thing and
just has different parameters I think it is reasonable.
eg.
object.Print; // default options;
object.Print(PrinterName : String); // to a specific printer object.Print(PrinterName : String; pageSize : Integer); // to a specific printer & pagesize.

Basically, if methods do different things shouldn't they have different names?

I would argue that creation procedures are doing the same thing for each case. Creating a new
instance of an object and setting it to a valid inital state (in Meyer-speak - it has to establish the class invariant)

On creation procedures: I don't think the way C++ creation procedures are defined is superior to JADE in anyway. It's not a big deal to create an object and then call a method on that object.

With Jade you're stuck with having different method names.

eg for a complex number class you might have.

create(); // create number at (0,0)
createPolar(rho, theta : Real); // create number with length rho, and angle theta.
createCartesian(x,y : Real); // create number with cartesian coordinates x,y

As Eric points out - its not a real hassle calling the methods yourself, as Jade doesn't call constructors automatically.

I suggest a convention like the one above where you have createXXX - where XXX tells you something about the parameters.
Make sure every class has the parameterless create() method.

Regards,
Carl Ranson

ps. I strongly recommend Meyers book mentioned above.

[ConvertFromOldNGs]

by Kevin Alcock >> Wed, 26 Jan 2000 23:19:16 GMT

Yes, very good reasons posted above, here is one for the other side. Lets take to constructor case. If I create a class call Person with a String attribute called name. Then a member key dictionary of people with name as the key ( not recommended, but hey its an example). I must always write code like this:

vars
p : Person;begin

beginTransaction;
create p;
p.setName("Oscar");
commitTransaction;
end;

what I would like to do is this:

vars
p : Person;begin

beginTransaction;
create p("Oscar");
commitTransaction;
end;

and have a create method like this:

create( n : String);begin

if n <> "" then
name := n;
else
// ABORT! ABORT! ABORT! ABORT! ABORT! ABORT! ABORT! ABORT!
endif;
end;

now what that does is make sure that the name will always be set to something. I agree that I could setup a convention to have a loadSelf or createXXX method. But the problem I want to solve here is I always want name to be set. I can always remember to follow my convention but in 6 or 12 months later when someone else has to add more code the is nothing to stop them from doing this:
begin
Transaction;
create p;
commitTransaction;

I hope that makes sense,

Kevin


ps: Is Meyer's first name Oscar?

[ConvertFromOldNGs]

by David Mitchell >> Sun, 30 Jan 2000 23:40:54 GMT

I agree with this. I hear what other people are saying, that if a method does something different it should have a different name, but I think the most important one would be the constructor (which jade DOES call automatically, on create). Passing parameters is almost essential to upholding the OO philosophy. "The constructor should prepare the object for life". That means after the constructor has run, the object should be entirely valid. But what Kevin's example with the Person means that an illegal object is created because it has no name, which could cause problems later on.

Question for JADE developers: Is there any chance that JADE might have this feature in the future? Either overloading methods, or at least passing parameters to the constructor?

David Mitchell
JADE Kid - 1998
www.jadekids.com

[ConvertFromOldNGs]

by Craig Shearer >> Mon, 31 Jan 2000 8:19:12 GMT

I agree that parameterised constructors are a deficiency in JADE, and it is frustrating to have to create and object then remember to call a method to initialise it.

However, I realise that adding parameterised constructors to the language would disturb the current syntax for object creation ie:

create customer;

whereas in C++ you're write (if I remember correctly!)

customer = new Customer("Fred");

It is almost as if the constructor is a class method which creates customer objects. So, if JADE introduced class methods then this could provide a solution to the problem. For example:

customer := Customer.createNew("Fred");

You'd still need to be able to protect the constructor so that it couldn't be called, and while the above would be nice, I must admit that having parameterised constructors would be much nicer, ie:

create customer("fred");

What do others think?

Craig.

[ConvertFromOldNGs]

by Dean Cooper >> Wed, 2 Feb 2000 4:00:27 GMT

Question for JADE developers: Is there any chance that JADE might have this feature in the future? Either overloading methods, or at
least passing parameters to the constructor?

Regarding method overloading. It's absence is not an oversight. Method overloading was considered in the early days of the JADE language and was left out deliberately. There are two schools of thought with respect to overloading, both of which have been represented at different times by different people in the design of the JADE. There are those who think overloading is useful, and those who think it isn't and adds unnecessary complexity and potential for ambiguity. We accept, though, that this is a bit of a religious argument, and there will always be those who disagree. However, at all times, we look to preserve the simplicity, brevity and conceptual economy of the JADE language, and we don't view overloading as necessary. There are more expressive features of higher priority that we would rather invest time in building, whereas overloading, as Meyer puts it, is "no more than a syntactic facility which relieves programmers from having to invent different names for different implementations of an operation". Method overloading is not being considered for any future JADE release at this stage.

Regarding parameters on constructors. We agree that constructor parameters are useful and it would be good to consider them in a future release (probably not 5.1 though). Our current thinking is to allow parameters to be specified in the create method, and add new syntax to the constructor signature to specify which parameters (if any) are to be passed to the superclass constructor (which may have a different number and/or type of parameters). You will still only be able to specify one create method per class though
(allowing multiple constructors a la C++ introduces overloading). One issue with this is that where you dynamically specify the type of an object in a create, the compiler won't be able to check the constructor parameters at compile time; it will have to be a runtime check. For example, in JADE you can write:

createSomething(c : Class) : Object;
vars
o : Object;begin

create o as c;
return o;
end;

Say we had new constructor parameter syntax, for example:

create o("hello", "world") as c;

The compiler cannot validate the constructor parameters because the type of object to be created is determined at runtime by "c" (it's constructor may not even take any parameters!). Languages like C++ don't support this kind of creation and therefore don't have this issue. Some people may object to this as a loss of type safety. These are the kind of issues we need to kick around.

Regarding an example that has been used in a couple of posts:
begin
Transaction;
create p("Oscar");
commitTransaction;

Even if you could pass "Oscar" as a constructor parameter, what do you do in the constructor if the name is null? Or invalid? Or a duplicate of another name? Typically you want to validate the parameters, so you need some way of indicating an error. You could have the constructor raise an exception, but then the example might look like:

on Exception do someExceptionHandler(exception);begin
Transaction;
create p("Oscar");
commitTransaction;
// and you also need the exception handler method

Or you could set a status on the object to indicate an error, and do something like:
begin
Transaction;
create p("Oscar");
if p.status = StatusOK then
commitTransaction;
// return the new object or something
else
abortTransaction;
// return some error
endif;

Or you may have an operation that needs to create Person objects in conjunction with several other related objects, and you may want to set only the attributes on all of the objects before setting the references between them (to avoid unnecessary key maintenance, for example). In this case, you can't do everything in the constructors.

The point here is that these cases have additional issues to deal with beyond just creating the object(s). Many frameworks have initialization methods (eg: initialize, create, etc) that you must call after actually constructing an object; even if you can pass parameters to the constructor. Such methods can then perform secondary initialization, validation, return an error code, whatever. The main issue is encapsulating the operations required to create an object. Typically you wouldn't inline the creation of Person objects everywhere you needed to create them. You'd often want to have a method (eg: createPerson that takes all the required parameters and validates them if necessary) on some owner/parent or factory object that encapsulates the creation of Person instances. In such a design, whether or not you can pass parameters to a constructor is of minimal consequence.

I agree that constructor parameters are a good idea, and it would be good to consider providing them in JADE in the future. But in most systems (certainly for your persistent objects) there is generally much more involved in preparing an object for life than simply executing its constructor.

Dean.

[ConvertFromOldNGs]

by Gregory Tolhurst >> Wed, 2 Feb 2000 19:32:37 GMT

<snip>

However, at all times, we look to preserve the simplicity, brevity and conceptual economy of the JADE language, and we don't view overloading as necessary.

This is an excellent declaration of intent from the plant.
I suspect that as newcomers to Jade we are delighted to discover its "simplicity, brevity and conceptual economy". (I might have added to Dean's list of virtues "self-referential integrity".) As we become closer acquainted with the product we start to wonder about more complex features, which threaten those virtues.

[ConvertFromOldNGs]

by Frank Pitt >> Sun, 30 Jan 2000 23:52:34 GMT

Yes, very good reasons posted above, here is one for the other side.

<snip>

now what that does is make sure that the name will always be set to something. I agree that I could setup a convention to have a loadSelf or createXXX method. But the problem I want to solve here is I always want name to be set. I can always remember to follow my convention but in 6 or 12 months later when someone else has to add more code the is nothing to stop them from doing this:

beginTransaction;
create p;
commitTransaction;

I hope that makes sense,

Makes perfect sense, and as far as I can tell is not possible in Jade because you cannot protect the constructor.

This is a huge problem for using 'proper' creational patterns on objects. You can't enforce the use of Factory classes for example, which is the obvious solution to your problem.

Of course, if all you're worried about is the name being non-null, then you can have a constructor that sets the name.

If for some reason you're worried about that being non-unique, then just define an automatic unique Dictionary on the class which will force people to catch the duplicate key exception. (assuming they ever test the code <grin> )

Not the nicest way of controlling creation, I'll admit, but it works !

ps: Is Meyer's first name Oscar?

Nope, it's Bertrand.

Frankie