Author Topic: Functions as TYPE members  (Read 3350 times)

Offline doimus

  • Dr. Type
  • ****
  • Posts: 284
    • View Profile
Functions as TYPE members
« on: 2009-Mar-10 »
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.

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10753
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
Re: Functions as TYPE members
« Reply #1 on: 2009-Mar-10 »
Do is this way:

FUNCTION animal_eatgrass: s AS animal, a
ENDFUNCTION

animal_eatgrass(sheep, 12)


Offline Schranz0r

  • Premium User :)
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 5069
  • O Rly?
    • View Profile
Re: Functions as TYPE members
« Reply #2 on: 2009-Mar-10 »
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]
« Last Edit: 2009-Mar-10 by Schranz0r »
I <3 DGArray's :D

PC:
AMD Ryzen 7 1700 @3.9GHz, 16GB HyperX Fury 3000MHz Ram, ASUS ROG GTX 1060 STRIX 6GB, Windows 10 Pro 64Bit, MSi Tomahawk B350 Mainboard

Offline doimus

  • Dr. Type
  • ****
  • Posts: 284
    • View Profile
Re: Functions as TYPE members
« Reply #3 on: 2009-Mar-10 »
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...

Offline Moru

  • Administrator
  • Prof. Inline
  • *******
  • Posts: 1790
    • View Profile
    • Homepage
Re: Functions as TYPE members
« Reply #4 on: 2009-Mar-10 »
Code: (glbasic) [Select]
TYPE animal:
    type = "sheep"
    ...
ENDTYPE

Hatonastick

  • Guest
Re: Functions as TYPE members
« Reply #5 on: 2009-Mar-10 »
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

Offline doimus

  • Dr. Type
  • ****
  • Posts: 284
    • View Profile
Re: Functions as TYPE members
« Reply #6 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

Offline AndyH

  • Dr. Type
  • ****
  • Posts: 383
    • View Profile
    • http://www.ovine.net/
Re: Functions as TYPE members
« Reply #7 on: 2009-Mar-10 »
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

  • Guest
Re: Functions as TYPE members
« Reply #8 on: 2009-Mar-10 »
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.