Would it be possible to have functions inside TYPE, something like this:
TYPE animal
size
weight
health
FUNCTION eatsomegrass: a
for i = 1 to a
print "Yum,yum!!",0,a*10
next
ENDFUNCTION
ENDTYPE
GLOBAL sheep AS animal
sheep.eatsomegrass: 12
This would be a step towards object oriented approach in GLB.
I guess there's a lot to be done "under the wraps" and things probably aren't as simple as I'm trying to make them look... but still, it would be nice to have this feature.
Do is this way:
FUNCTION animal_eatgrass: s AS animal, a
ENDFUNCTION
animal_eatgrass(sheep, 12)
doimus: I agree.
I think its a lot of work to implement that "method-feature" on types...
But its a f***ing nice one :D
[DREAM]
(a stupid example)
TYPE Player
spriteID%
x%;y%
METHOD SetPosition(x%,y%)
THIS.x = x
THIS.y = y
ENDMETHOD
METHOD DrawPlayer()
DRAWSPRITE THIS.spriteID, THIS.x, THIS.y
ENDMETHOD
ENDTYPE
GLOBAL _Player[] AS Player
LOCAL PlayerOne AS Player
PlayerOne.spriteID = 1
PlayerOne.SetPosition(100,300)
WHILE TRUE
PlayerOne.DrawPlayer()
SHOWSCREEN
WEND
END
[DREAM END]
It would be a killer feature, as it is difficult to go back once you taste the benefits of OOP.
@Gernot:
Is there a way to make function avare of which "instance" of TYPE it was called from?
ie. can the function know whether it was called from a sheep or a dog animal?
SETSCREEN 640, 480, 0
GLOBAL sheep AS animal
GLOBAL dog AS animal
PRINT "Which animal:",0,0
LOCAL an$
INPUT an$, 0,10
IF an$ = "sheep" THEN eat_grass (sheep, 12)
IF an$ = "dog" THEN eat_grass (dog, 2)
SHOWSCREEN
MOUSEWAIT
FUNCTION eat_grass: s AS animal, a
IF s = sheep
FOR i = 1 TO a
PRINT "Yum! Yum!", 0, i*20
NEXT
ENDIF
IF s = dog
PRINT "I ain't eating no grass, dammit!",0,0
ENDIF
ENDFUNCTION
TYPE animal
health
ENDTYPE
This example produces some weird results, since s is both sheep and dog at the same time...
TYPE animal:
type = "sheep"
...
ENDTYPE
Well if OOP is ever added to GLB, I hope it will be optional. I'm old and set in my ways -- yes, I can do OOP, I just don't like it. =D
Quote from: Moru on 2009-Mar-10
TYPE animal:
type = "sheep"
...
ENDTYPE
I did it like that. It's kind of double-workaround and it leaves A LOT of space for logical errors and other nasty stuff, but hey, it works!
Here's the revised code:
SETSCREEN 640, 480, 0
GLOBAL sheep AS animal
sheep.kind$ = "sheep"
GLOBAL dog AS animal
dog.kind$ = "dog"
PRINT "Which animal (sheep or dog):",0,0
LOCAL an$
INPUT an$, 0,10
IF an$ = "sheep" THEN eat_grass (sheep, 12)
IF an$ = "dog" THEN eat_grass (dog, 2)
SHOWSCREEN
MOUSEWAIT
TYPE animal
health
kind$
ENDTYPE
FUNCTION eat_grass: s AS animal, a
IF s.kind$ = "sheep"
FOR i = 1 TO a
PRINT "Yum! Yum!", 0, i*20
NEXT
ENDIF
IF s.kind$ = "dog"
PRINT "I ain't eating no grass, dammit!",0,0
ENDIF
ENDFUNCTION
I'm in with the "for" camp to add some basic OOP to GLB. I really do not understand why some are reluctant to use it if it were there, but as you can see in the above code snippets it wouldn't change anything for those that didn't want to use it. You would just create functions and types as you do now, but for those who want to, we could put functions (or methods) in the type structures too to make a more self contained object. This would make both camps happy.
Functions in types is certainly very BlitzMax/C++ and certainly has its advantages (if its optional) : Routines can be compartmentalised which should help program development.
I wouldn't mind if it's added, although I'm sure Gernot has more pressing things to add in GLBasic before thinking about this sort of thing.