Overloaded Methods

[ConvertFromOldNGs]

by cnwsc2 >> Tue, 25 Mar 2003 1:00:39 GMT

There have been requests for an overload methods as a NFS and I wish to share my ideas on how it could be done in Jade to get feedback before adding as a NFS to Jade.

A method type would be created called a 'redirected' method which would be selected in a checkbox on the 'create new jade method' form.

To do this the 'method' class it would have a collection of other methods that it uses when redirecting the method which has an inverse to handle the deletion of the overloaded methods.

This collection would only be used by the 'redirected' method type.

The 'redirected' method would be set up by a redirector form where you add a methods from anywhere in the schema to the 'redirected' method.

This would also show what 'overloaded' methods are attached and their order of selection in this form as well.

When this method is invoked it would try in the order all the other methods in the

'redirector' overload methods collection getting the most correct parameters and return type.

It would first try to match by the parameters first , then the return type and finally there are more than one methods that match these criteria ,by the order of these methods in the collection.



Eg A redirected method called mDrawBox() has these methods as its overloaded methods

1)mDrawBox2(x : Integer , y : Integer);

2)mDrawBox3(xy : Integer);

3)mDrawBox4(xy : Integer, a :String);

4)mDrawBox5(xy :Integer): String

5)mDrawBox6(x :String)



When the Jade code executes mDrawBox(10) it would find that both (2) and (4) match the type of parameters.

Note (5) is not used because it needs a string type parameter.

Then it looks at the return type and finds that (2) matches the return type.



It would then attached the mDrawBox(xy) to the mDrawBox3(xy) method.

This would be easily to do when the F8 compiles the mDrawBox(10) method it would at that point set the reference of what method to invoke.

This redirector method would have no parameters and no return type and no jade code could be entered into the 'redirected' method but text could be enter into the method to document it.

All the redirector method purpose is to redirect what method is executed when it is invoked.

To support it the Ctrl 3 bubble help on the parameters for a method would cycle through the various overloaded methods attached to a 'redirector' method.

When creating these methods you would F-11 on the method to check what 'overloaded' method the ''redirected' method that it would invoke.

You thoughts and feedback

[ConvertFromOldNGs]

by Patwos >> Tue, 25 Mar 2003 2:02:13 GMT

I have never found a situation where an overloaded method would for me take preference over just creating a new method with the additional/changed parameters. Generally, if the method has a different requirement in terms of it's parameters then thats enough in my book to warrant a new method with the appropriate parameters.

Appropriately named methods for the different requirements can make it much clearer what is being attempted rather than just reusing the same named method and overlaying a different set of parameters - particularly given programmers always abuse features given the opportunity.

You can therefore put me down in the school of people who see overloading and optional parameters as adding unnecessary extra opportunity for things to go wrong and would prefer not to see these constructs added to the JADE Language.

Thats my $0.02.

Cheers,
Patwos.

[ConvertFromOldNGs]

by cdshearer >> Tue, 25 Mar 2003 2:22:27 GMT

Your description seems very very convoluted, especially the way in which Jade would choose which method to execute. I think that distinguishing methods on their return type would be very dangerous, after all, one is never required to use the return value from a method.

However, I am a fan of overloaded methods... but I think that the higher priority would be parameterised constructors (which require overloaded methods anyway, so I'm told.)

Craig

[ConvertFromOldNGs]

by cnwsc2 >> Wed, 26 Mar 2003 11:55:38 GMT

Sorry about my description being very convoluted but I was trying to give as much detail as possible than just a rough outline.

Thinking about your comments

I think that distinguishing
methods on their return type would be very dangerous, after all, one is never required to use the return value from a method.

did make me think that I do need to remove the return type from the selection criteria for selecting the overloaded method. Not for the reason listed as a method having no return type. I think is ok but that it would an required analysing the source code to see what return type the method needs. This I think is just to messy to do as the coding required for this NFS needs to be as simple as possible.

Thanks.

Shane

[ConvertFromOldNGs]

by allistar >> Tue, 25 Mar 2003 7:36:18 GMT

As others have said I think that true overloading of methods is not necessary for a language like Jade. I do, however, think it would be useful to have methods which have optional parameters (and that you can default the values to be used if none are passed in). Obviuosly these parameters must be at the end of the methos signature.

Like this:

someMethod(supplier: Supplier; string: String; printInvoices = false: Boolean);

the last parameter would not be required when invoking this method.

Regards,
Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz ------------------------------------------------------------------

[ConvertFromOldNGs]

by cnwsc2 >> Wed, 26 Mar 2003 12:57:15 GMT

I somewhat agreed with you that overloading is not necessary for a language like Jade as you that can write good code without this functionally as all you are doing is selecting what method that you want to run in the source statement line.

You can either get the complier to do it (overloading) or you can manually selected the method from your own logic and the method naming conventions that you want to use.

The main crutch behind this suggestion was how would you implement overload methods without adversely affecting any other functionally of Jade.



You suggestion of default values for parameters (a C++ type functionality) could also easily be done by this 'redirector idea' having their overloaded methods referring to each other with the default parameter.



Eg A redirected method 'someMethod' would have these overloaded methods

someMethod1(supplier: Supplier; string: String);

someMethodAllCode(supplier: Supplier; string: String, printInvoices : Boolean);



someMethod1(supplier: Supplier; string: String);
begin


someMethod(supplier,string,false);

end;



someMethodAllCode(supplier: Supplier; string: String; printInvoices : Boolean);
begin


// the real code it here.

end;



But with these 'redirected' methods you could easily have default objects which would be hard to implement with just using 'default' values for parameters.

Eg
SomeMethod2(supplier: Supplier; string: String);

vars
myCustomer : Customer;
begin


if supplier = null then

myCustomer := app. myCustomer;

else

myCustomer := Supplier. myCustomer;

endif;

someMethod(supplier,string, myCustomer);

end;



One point , if your idea of default values did happens it would be easier for the tokenising of the parameters for the default value coming after the type of the parameter.

It also it would affect the appearance of the formatting of the parameters the least.

Eg someMethod( supplier : Supplier;

string : String ["Kiwi'];

printInvoices : Boolean [false]);


Thanks for comment and ideas.

Shane.

[ConvertFromOldNGs]

by CarlRanson >> Thu, 27 Mar 2003 4:32:27 GMT

Why on earth would this bit be needed at all? Surely Jade should be able to resolve the correct method to call based on the number and types of parameters.
Unless the goal is to also allow multiple methods with the same signature (parameters and return types) which doesnt make much sense to me.

What do you propose for the inheritance behaviour?
CR

[ConvertFromOldNGs]

by cnwsc2 >> Fri, 28 Mar 2003 4:38:18 GMT

You are correct with your comments.

The order of their listing in the selection box should not matter.

To ensure that is only one combinations of method types as parameters for an 'overload' method in selection process ,some sort of checking would have to be done.



Also you are right again that you should only be able to use methods from your class or super class.

That last point I should have picked up earlier.



With some of this good feedback that I have been getting I have created the 1.1 version NFS suggestion.



Maybe to explain this version better let me go through a possible scenario of creating a 'redictor' method and its usage.



1)You have created some methods to use for overloading.



2)You create a 'redirector' method in this manner.

You write right click to bring up the context menu.

You select the option New &Redictor which is just below the New &External Method.



A new form comes up like the standard one used when you add a new 'Jade' method but it

has two listboxs side by side but with no option to set its visibility. One listbox holds all the non abstract methods in the class and from its super classed version up to the root schema.

The other list holds the 'overloaded' methods for this 'redirector' method.



You add a name for the 'redirector' eg 'mDrawBox'



You select the three methods from the current class from the left listbox to the right listbox .

They are

mDrawBow1(x : Integer) updating;

mDrawBow2(x : Integer, y : Integer) updating :

mDrawBox3(x : Integer, y : Integer, colour : Integer) : bollean

You click "ok"



A new method appears for the class.

It has different icon picture of a green arrow.

It appeared at the top of the list in the method listbox just before the public classes.

In the editor pane you see.

mrDrawBox() redictoredMethod;

public mDrawBow1(x : Integer) updating;

protected mDrawBow2(x : Integer, y : Integer) updating :

protected mDrawBox3(x : Integer, y : Integer, colour : Integer) : Boolean



You cannot change this text in the editor pane.



3) You write another method to test it



mTestDrawBox()

vars
begin


mrDrawBox(

end



4)You press Ctr-3 just after the brackets.

It cycles through the different overloaded methods to see what overloaded methods there are.



5)You enter the your choice.

mTestDrawBox()

vars
begin


mrDrawBox(10,20);

end;



and press F8 to compile.

In the compiler it sees that mrDrawBox is a 'redirector' method and works out what method on the class to use.

The reference to mrDrawBox method is now 'redirected' to the correct method.



6) To change the 'redirector' method highlight it in the method list box and now the context menu says Edit 'Redector' instead which will load the same form that you used to enter a new 'Redirector' method but with the 'overloaded' methods preloaded in the right listbox.



Easy. :*)


I think the hardest part of coding this would be the modifications to the schema/method create and load methods.



'Note it is easier to admit that you are wrong than travel down the path of delusion and ignorance'.

Shane.

[ConvertFromOldNGs]

by carlranson >> Sun, 30 Mar 2003 6:15:01 GMT

Seems a bit complicated to me. All this work to specify the "redirector" method should not be necessary at all.

why cant you just add your 3 methods with the same name:
mDrawBox(x : Integer) updating;
mDrawBox(x : Integer, y : Integer) updating :
mDrawBox(x : Integer, y : Integer, colour : Integer) : Boolean;

Jade can then work out which one to call based on the number and types of paramters you pass it. No need to do anything special except add a new method with the same name. Changes to jade would be limited to allowing multiple methods with the same name and working out which method is intended from the parameters.

Bascially, the method's ID goes from being the name only to the name and parameters (the signature). Jade would need to raise a compile error when a method with the same signature as an existing one was created, but apart from that it shouldnt be a big deal.

CR

[ConvertFromOldNGs]

by cnwsc2 >> Mon, 31 Mar 2003 7:05:57 GMT

You are correct with your comments.

The order of their listing in the selection box should not matter.

To ensure that is only one combinations of method types as parameters for an 'overload' method in selection process some sort of checking would have to be done.



Also you are right again that you should only be able to use methods from your class or super class.

That last point I should have picked up earlier.



With some of the good feedback that I have been getting I have created the 1.1 version NFS suggestion.



Maybe to explain this version better let me go through a possible scenario of creating a 'redictor' method and its usage.



1)You have created some methods to use for overloading.



2)You create a 'redirector' method in this manner.

You write right click to bring up the context menu.

You select the option New &Redictor which is just below the New &External Method.



A new form comes up like the standard one used when you add a new method but it

has two listboxs side by side but with no option to set its visibility. One listbox holds all the non abstract methods in the class and from its super classed version up to the root schema.

The other list holds the 'overloaded' methods for this 'redirector' method.



You add a name for the 'redirector' eg 'mDrawBox'



You select the three methods from the current class from the left listbox to the right listbox .

They are

mDrawBow1(x : Integer) updating;

mDrawBow2(x : Integer, y : Integer) updating :

mDrawBox3(x : Integer, y : Integer, colour : Integer) : bollean

You click "ok"



A new method appears for the class.

It has different icon picture of a green arrow.

It appeared at the top of the list in the method listbox just before the public classes.

In the editor pane you see.

mrDrawBox() redictoredMethod;

public mDrawBow1(x : Integer) updating;

protected mDrawBow2(x : Integer, y : Integer) updating :

protected mDrawBox3(x : Integer, y : Integer, colour : Integer) : Boolean



You cannot change this text in the editor pane.



3) You write another method to test it



mTestDrawBox()

vars
begin


mrDrawBox(

end



4)You press Ctr-3 just after the brackets.

It cycles through the different overloaded methods to see what overloaded methods there are.



5)You enter the your choice.

mTestDrawBox()

vars
begin


mrDrawBox(10,20);

end;



and press F8 to compile.

In the compiler it sees that mrDrawBox is a 'redirector' method and works out what method on the class to use.

The reference to mrDrawBox method is now 'redirected' to the correct method.



6) To change the 'redirector' method. Highlight it in the method list box and now the context menu says Edit 'Redector' instead which will load the same form that you used to enter a new 'Redirector' method but with the 'overloaded' methods preloaded in the right listbox.



Easy. :*)


I think the hardest part of coding this would be the modifications to the schema/method create and load methods.



'Note it is easier to admit that you are wrong than travel down the path of delusion and ignorance'.


Oops I forgot to answer the question about inhertance.
An inherited redictored method inherts its super classed 'overloaded method' when you create it.
This means they are preloaded in the right list box on the 'add new redictor method' form.
They can be removed if required.
Each redirector method acts for that schema and and it superschema's until the super schema
has its own inhertied 'redirector method' or not.
I think this is the easest way to do this.
Shane