Why use ABSTRACT instead of an empty method body

Monkey Forums/Monkey Programming/Why use ABSTRACT instead of an empty method body

MikeHart

(Posted 2011) [#1]

Something I am still not getting. Why should I use ABSTRACT for an empty method body? Is it because then you must define it in the class you extended the base class from and it isn't optional

So far I use empty method bodys, which then I CAN overwrite them inside the new class.

Goodlookinguy

(Posted 2011) [#2]

The way of writing programs using abstract methods is just a object oriented programming philosophy. The intention is to say, classes that extend this must have the parent's functionality, but implemented the way that the extended class implements them. Same thing with interfaces, it's just using a OOP philosophy.

The difference in an empty method and abstract, is as you said. One will force you to have them as your implementation, while the other has it's parent method to fall back on if you don't define it.

MikeHart

(Posted 2011) [#3]

Thanks, nice cartoon. These empty classes I have a callback classes. In som eapps you will need some of them, in other apps you need the others. That is way they are not mandatory and so not being defined as Abstract.

Samah

(Posted 2011) [#4]

MikeHart: That is way they are not mandatory and so not being defined as Abstract.

The class can still be abstract, but the methods can be left as empty implementations.

Class Test Abstract
  Method Foo:Int()
  End

  Method Bar:Int() Abstract
End

In this code snippet, you are only forced to implement the Bar method when extending Test. It will inherit Foo with an empty implementation.

FlameDuck

(Posted 2011) [#5]

In som eapps you will need some of them, in other apps you need the others. That is way they are not mandatory and so not being defined as Abstract.

This is probably not a terribly good idea as there is nothing preventing a user from supplying a wrong callback class (that is your callbacks aren't typesafe, and could fail or do nothing, creating difficult to track down unexplained behavior). A better solution would be to create an Interface for each type of callback you need (much like the way you "fake" delegates in Java, this can be applied to Monkey as well).

The class itself can then implement all the necessary interfaces, and the compiler will throw an error if you give the function that needs the callback a wrong type of object.

MikeHart

(Posted 2011) [#6]

What I would really need is function pointers. :-/

What I have now is an engine class (ftEngine) and an object class (ftObject). The engine class is the only one that gets extended. Inside your code you tell the engine to create a new object. The engine will store it inside a objectlist which is a property of ftEngine. Objects have buildin methods like Scale, Rotate, Spin, etc.
When you call the engine's update method, it then loops through all the objects inside the list and updates their properties depending on the objects settings.
During the updating process, I have a call to a OnObjectUpdate(obj:ftObject) method, which is defined inside the engine class. It is an empty method that could be overwritten inside the extended engine class.

I am not against Abstract or interfaces, I just don't see where they could help me with my approach.

Here is a could example:

Strict

Import fantomEngine
Global g:game

'***************************************
Class game Extends App
	Field eng:engine
	Field ball:ftObject
	Field deltaTime:Int
	Field lastTime:Int
	Field cw:Int
	Field ch:Int
	'------------------------------------------
	Method GetDeltaTime:Int()
		deltaTime = Millisecs() - lastTime
		lastTime  += deltaTime
		Return deltaTime
	End
	'------------------------------------------
	Method OnCreate:Int()
		SetUpdateRate(60)
		eng = New engine
		cw = DeviceWidth()
		ch = DeviceHeight()
		ball = eng.CreateCircle(15, cw/2, ch/2)
		ball.SetSpeed(10,45)
		Return 0
	End
	'------------------------------------------
	Method OnUpdate:Int()
		Local d:Int = GetDeltaTime()
		eng.Update(Float(d)/60.0)
		Return 0
	End
	'------------------------------------------
	Method OnRender:Int()
		Cls (255,0,0)
		eng.Render()
		Return 0
	End
End	

'***************************************
Function Main:Int()
	g = New game
	Return 0
End

'***************************************
Class engine Extends ftEngine
	'------------------------------------------
	Method OnObjectUpdate:Int(obj:ftObject)
		Select obj
			Case g.ball
				If (obj.yPos < obj.GetHeight()/2 And obj.GetSpeedY() < 0) Or (obj.yPos > (g.ch - obj.GetHeight()/2) And obj.GetSpeedY() > 0) Then 
					obj.SetSpeedY(-obj.GetSpeedY())
				Endif
				If (obj.xPos < obj.GetWidth()/2 And obj.GetSpeedX() < 0)  Or (obj.xPos > (g.cw - obj.GetWidth()/2) And obj.GetSpeedX() > 0) Then 
					obj.SetSpeedX(-obj.GetSpeedX())
				Endif
		End
		Return 0
	End
End

FlameDuck

(Posted 2011) [#7]

What I would really need is function pointers. :-/

You might *want* them, because they're the way you usually solve this type of problem, but you don't really *need* them.

I'm not quite sure what your example is trying to do, Except use Select / Case where you could get away with Polymorphism.

Here is an example of what I mean:

Strict

Import mojo

Interface IUpdateable
	Method OnUpdate:Int()
End

Interface IRenderable
	Method OnRender:Int()
End

Class AbstractEntity Abstract
	Global cw:Int
	Global ch:Int

	Method New (cw:Int, ch:Int)
		Self.cw = cw;
		Self.ch = ch;
	End

End

Class Ball Extends AbstractEntity Implements IUpdateable, IRenderable
	Field x:Int
	Field y:Int
	Field xs:Int
	Field ys:Int

	Method New ()
		Self.x = 0
		Self.y = 0
		Self.xs = 1
		Self.ys = 1
	End

	Method New (cw:Int, ch:Int)
		Super.New(cw, ch)
		Self.x = 0
		Self.y = 0
		Self.xs = 1
		Self.ys = 1
	End
	
	Method OnUpdate:Int()
		Self.x += xs
		Self.y += ys
		If Self.x > Self.cw-16 Or Self.x < 0
			Self.xs =- Self.xs
		End
		If Self.y > Self.ch-16 Or Self.y < 0
			Self.ys =- Self.ys
		End
	End

	Method OnRender:Int()
		DrawCircle Self.x, Self.y, 16
	End
End

Class Pad Extends AbstractEntity Implements IUpdateable, IRenderable
	Field x:Int
	Field y:Int
	Field xs:Int
	
	Method New ()
		Self.x = 0
		Self.y = ch - 16
		Self.xs = 1
	End
	
	Method New (cw:Int, ch:Int)
		Super.New(cw, ch)
		Self.x = 0
		Self.y = ch - 16
		Self.xs = 1
	End

	Method OnUpdate:Int()
		Self.x += xs
		If Self.x > Self.cw-64 Or Self.x < 0
			Self.xs =- Self.xs
		End
	End

	Method OnRender:Int()
		DrawRect Self.x, Self.y, 64, 8
	End
End

Class game Extends App

	Field ball:Ball
	Field pad:Pad

	Method OnCreate:Int()
		SetUpdateRate(60)
		ball = New Ball(DeviceWidth(), DeviceHeight())
		pad = New Pad()
		Return 0
	End

	Method OnUpdate:Int()
		ball.OnUpdate()
		pad.OnUpdate()
		Return 0
	End

	Method OnRender:Int()
		Cls 0,0,0
		ball.OnRender()
		pad.OnRender()
		Return 0
	End
End	

Function Main:Int()
	New game
	Return 0
End

AdamRedwoods

(Posted 2011) [#8]

I think another reason we're seeing INTERFACE and ABSTRACT is less for use quick, one-file games-- but more to encourage third-party frameworks to be used with Monkey.

If you write a separate imported module that you want to re-use with other games, then those two commands come in handy because you won't have to dig through the code to debug something you missed, it'll error out and tell you.
(although we usually dig anyways)

Samah

(Posted 2011) [#9]

@FlameDuck: You declared cw and ch in AbstractEntity as global. :)

MikeHart

(Posted 2011) [#10]

Thanks guys for the input!