Functions as TYPE members

Previous topic - Next topic

doimus

Would it be possible to have functions inside TYPE, something like this:

Code (glbasic) Select

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.

Kitty Hello

Do is this way:

FUNCTION animal_eatgrass: s AS animal, a
ENDFUNCTION

animal_eatgrass(sheep, 12)


Schranz0r

#2
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)
Code (glbasic) Select
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]
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

doimus

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?

Code (glbasic) Select

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...

Moru

Code (glbasic) Select
TYPE animal:
    type = "sheep"
    ...
ENDTYPE

Hatonastick

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

doimus

Quote from: Moru on 2009-Mar-10
Code (glbasic) Select
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:
Code (glbasic) Select

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


AndyH

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.

MrTAToad

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.