NewsForumsCodeLogsGallerySpecsSearch

overriding methods

Monkey Forums/Monkey Programming/overriding methods

NoOdle(Posted 2012) [#1]
is it possible to do this cleanly:
Class Foo
	Method someMethod : Void()
	End Method
End Class

Class Bar Extends Foo
	Method someMethod : Void( extra : Int )
	End Method
End Class

Function Main()
	Local b:Bar = New Bar()
	b.someMethod( 10 )
End Function


I could put someMethod : Void( extra : Int ) into the Foo class as well and make that call someMethod() but that leaves a gap for Bar to call someMethod() which I don't want and I'm not sure how to make that safe, a warning to the user perhaps.

I guess I could replace the method in Foo with someMethod : Void( extra : Int = 0 ) but that has limitations, I won't be able to change the method parameters for other extended classes.

I'm not really keen on either and I can't seem to figure out the best way to solve this problem. Please forgive any stupidity on my part, its late and I'm tired!


Jesse(Posted 2012) [#2]
will you be calling the foo method from an extended class? if not you can make it private.

[edit]

I thought I had done something like that before but I tried it now and it doesn't seem to work.

and I think it should but I am not an expert on this subject so I'll wait for other comments.


Gerry Quinn(Posted 2012) [#3]
You could put:



Of course that only stops anyone calling it from Bar.

You could declare the void method in an interface, then all classes would have to handle it. But that's a lot of typing just to stop something happening that shouldn't happen.

If there is some way of keeping it private as suggested by Jesse it would be ideal.


ziggy(Posted 2012) [#4]
In Monkey it is not legal to add additional overrides on derived classes. Wich in my opinion is something great.


NoOdle(Posted 2012) [#5]
will you be calling the foo method from an extended class? if not you can make it private.

unfortunately yes as not all extended classes need anything more than the foo method.

I thought I had done something like that before but I tried it now and it doesn't seem to work.

Yea I was sure I had done this before as well, I was stumped when it didn't compile. Checked in Obj-C and it is permissible so I assume Im getting muddled up with that.

Of course that only stops anyone calling it from Bar.

Yea that was one of the options I was faced with last night, unfortunately it still requires the additional method to be placed in Foo as well unless Interfaces can solve this...gonna have a play with them now, not needed to use them before.

The actually scenario is to do with my framework. The base class or Foo in this example is actually a 2d node that controls position, rotation, scale, colour, parent/child relationships etc etc. The method is AddChild() and obviously any extended class like a Sprite would use that as well. It wasn't until I started to write an extended class to handle Parallax Scrolling that I noticed I would have trouble. I wanted to be able to use AddChild to specify a few additional parameters like the parallax ratio and wrapping without having to modify the way the framework functions. For example, I didn't want to write special parallax versions of all the extended nodes just to handle a couple of extra parameters. Likewise I don't want to bloat the base class with additional parameters that only a handful of nodes will use. The parallax node can have any node as its children, its automagically updated and rendered correctly based on the parallax ratio of the child. The also handle wrapping, allowing infinite backgrounds or random parallax one offs like a tree. Trying to keep the framework simple and consistent is proving slightly trickier than I had anticipated.


Gerry Quinn(Posted 2012) [#6]
Ziggy said: "In Monkey it is not legal to add additional overrides on derived classes. Wich in my opinion is something great."

I never knew that, but I just tried it and you're right.

Personally, I'm not sure I like it, but then again it never bothered me so I guess it's not going to cramp my style too much. I can see how it can prevent some errors.


NoOdle(Posted 2012) [#7]
I think the easiest way to handle this is change the base class so that AddChild() takes an object as a parameter. This can be used to store additional information.
Method AddChild( param : Object = Null )
The extended classes can then make use of the param object passing in an instance of a specific data class containing information relating to the extended node. Warning can be given if the param is null or of the wrong type for the extended class.

If anyone can see a more elegant solution I will be very happy!