controlling method inheritence

[ConvertFromOldNGs]

by johnmunro >> Fri, 30 May 2003 11:05:01 GMT

Does anyone else think we need more control over method inheritence in Jade? It would be really handy to be able to specify MustInherit or CannotInherit on methods...

Also, and I'm not sure how this could be solved, some sort of method signature polymorphism, so if you had SuperClass with a method setup(one : Boolean; two : Boolean) you could have a SubClass with a method setup(one : Boolean; two : Boolean; three : Boolean). I mean, the point of a suclass is to encompass all of the functions of the superclass and add new functionality, so why can't we have methods which do everything the superclass method does and then some...

--
John Munro

Synergist Limited - Home of FileVisionT
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS
Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

[ConvertFromOldNGs]

by michaelj >> Fri, 30 May 2003 17:20:17 GMT

John,
Search the feature discusion group for a discussion on method overloading.

I am not sure whether I like the suggested implementation but this would achieve what you are trying to do. Personally I would much prefer operator oveloading as this is something poweful that would help keep jade simple. Method oveloading unless implemented in a very straight forward manner will likely make jade coding less developer friendly.

Regarding your first point, Do you mean force/prevent classes from actually inheriting a given method or rather just force/prevent classes from implementing a given inherited method? In either case I believe jade 6 may help you in this matter. However I think the latter option would be a lot more pure. Why would an objects class be categorised as belonging to a super class, if that object could not use all that super classes behaviour/functionality? Sounds more like a peer situation ( within another different superclass) than a child. Thats my 2p anyway.

Michael J

[ConvertFromOldNGs]

by cnwdad1 >> Sat, 31 May 2003 23:12:03 GMT

JADE 6 has a feature to prevent a method from being reimplemented any further than the current implementation.

With regard to method overloading, I've found that using proxy objects for parameters is an easier and more flexible solution.

regards,
darrell.

[ConvertFromOldNGs]

by encos_dev >> Tue, 10 Jun 2003 21:51:59 GMT

Hi,

I'm not 100% sure on what the OO terminology for it is, but it would be great if you could change the method signature of a method in a sub class (i.e. add in parameters & add in a return type).

I've just come across a situation where I'm trying to extend code from a 3rd party schema & as I can't change the method signature I have to write 'extended' methods and copy code from the original. This in turn is creating a nightmare of code.

Is this a common problem in other OO languages? or would the ability to change the method signature solve this problem.

Cheers,

Glen
Encos

[ConvertFromOldNGs]

by michaelj >> Wed, 11 Jun 2003 16:18:52 GMT

Glen,
Method overloading could achieve what you describe. It effectively allows you to have multiple definitions of the same method (name) on a class or subclass. When the interpreter encounters a call to a method it then would bind that call to whichever definition matched the supplied parameters. Works well in loosely typed languages, but Im not sure how it could be easily implemented ( and used ) in jade.

With regards to code copying, can you not just define a method that calls the parent class method + does what you want the subclass method to perform? Sure you will have one extra method call but I think it is better than code copying

i.e

parentClass::setup( param1 );

subClass:: setupSubClass( param1 , param2);
begin
...... // subclass setup
setup( param1);
end;

Michael.

[ConvertFromOldNGs]

by JensRichnow >> Wed, 11 Jun 2003 23:07:38 GMT

Apparently a never ending story re method overloading and overriding in Jade, i.e., the lack thereof. Yes, it would be very good to have it. No, the developers should not deal with potential cumbersome solutions to achieve it. Yes, it should be transparently implemented by Jade. There are many languages out there that support it.

As a side line: It appears that there are many Jade systems out there with a very deep inheritance chain. What happened to the loose coupling and usage of simple design patterns? Depending on the application logic a simple Facade and/or Adapter can give you what you want for the time being.

[ConvertFromOldNGs]

by encos_dev >> Fri, 13 Jun 2003 1:53:15 GMT

Michael,

The whole reason I was sub-classing in the first place was because I was trying to extend code in the 3rd party schema, & I didn't want to touch the code in the 3rd party schema.

The only change I wanted to make to the method in question was to have it return the object that it was creating. Calling the super class method from the sub class wouldn't give me the object, so I had to copy the code to extend it.

Since my post, thought, I have discovered I can add code to classes from a super schema in a sub schema (leaving the super schema untouched), effectively meaning I can better re-use the code (in this case I could add my extended method directly to the 3rd party class) & have, as such, managed to avoid the code 'nightmare' I mentioned. It may seem like I had missed the obvious, but I've never needed to 'extend' third party code before.

Hope this makes sense. I'm learning as I go which is important for me. Thanks for your input.

Cheers,


Glen