Uhm, well.
I don't like it. I won't support it much, but you asked for it until my ears were bleeding.
First, the TYPEs should soon be able to have functions as members as well as a "self" variable pointing to it self.
TYPE Tvec
x;y;z
FUNCTION null:
self.x = 0; self.y=0; self.z=0
ENDFUNCTION
FUNCTION add: v AS Tvec
INC self.x, v.x
INC self.y, v.y
INC self.z, v.z
ENDFUNCTION
ENDTYPE
LOCAL vec AS Tvec, vec2 AS Tvec
vec.null()
vec.x=50
vec2.x = 100
vec.add(vec2)
Also, I think about including the AS standard types: double, float, int, short, char.
It will be a version 8.x upgrade. We have 7.x for about a year now - time to increase the version number :P
Here's a beta patch of the GPC you need. If you're uncertain how to install it, don't!
Do backup before you replace it. I've built some old projects ok with it, but there was times when it made really nasty and hard to identify errors. Be warned. Don't use it for an AppStore release unless you really thoroughly tested the output.
http://www.glbasic.com/beta/platform.rar (http://www.glbasic.com/beta/platform.rar)
lol
GREAT!
but you'll regret it, I'm sure.
don't forget to offer PRIVATE, PUBLIC for TYPE members :)))
yeeeaaahhh!!!!
thanks!
Functions in types? Interesting...
I like that part about standard types, I was kind of missing those.
Not keen on functions in types, start of the slippery slope down OOP :puke: ... but I do know folk want it.
Quotedouble, float, int, short, char
Now this is something I would like to see, its a definite step to towards easy C library compatibility, which would open a whole world of possibilities for me.
Congrats Gernot, nothing easy to do in that post, much appreciated! :enc:
:booze: :enc:
[attachment deleted by admin]
<3 I love you! <3
:happy: :nw:
On your post you forgot the white flag gernot ;) -> :giveup:
Thank you so much!
Edit:
You implement this feature on your GLBasic version, and it work?!
QuoteOn your post your forgot the white flag gernot
Based on Gernot's feelings about the new feature, it is more like >:D
:D also a good smily :D
Ah, nice Gernot, that will allow more OOP style with methods.
Please though, don't allow OOP to take over to the point it is required.
OOP is great when it can be used as a tool as needed.
Thanks.
@ Schranz0r - I just want to mention, I love your avatar, it makes me smile everytime I see one of your posts. =D
Did you make that character?
regards,
Dave
Quote from: aonyn on 2010-May-01
@ Schranz0r - I just want to mention, I love your avatar, it makes me smile everytime I see one of your posts. =D
Did you make that character?
No i find that picture in the WWW :)
Thats my
ABSOLUT FAVORIT Avatar :)
Haha, just smiled again =D
Definately one of the best avatars I have ever seen.
regards,
Dave
:happy: Thank you :enc:
I am rather partial to this ostrich head:
(http://jascm.files.wordpress.com/2009/03/ostrich_head.jpg)
YIKES!!!! :blink:
Cool............tks 8)
yes that would be great
Brrr! :giveup:
:P
Hmm i think thats not realy a "Must have" :)
It some ways, it seems like what made GLB a great language syntax wise is slowly being chipped away. GLB used to be a rock-solid BASIC, now it is going to be another half-assed OOP implementation like BlitzMax?
Quote from: Kitty Hello on 2010-Apr-30
Uhm, well.
I don't like it. I won't support it much, but you asked for it until my ears were bleeding.
If you don't like it, you shouldn't do it ;)
why - o why did I start that at all...
It's giving me great headaches just to get the basics running again, and there's a wish list that's blowing my mind...
Here it is: :giveup: :D
I must admit I am a little worried about this, it all seems pretty harmless but the OOP disaster that was the conversion from Blitz3D to BlitMax, destroyed an otherwise vibrant large community.
Yes, its optional but that can lead to fragmentation of users, into OOP and non-OOP ones.
Who knows, maybe it will be a good thing but I don't see me using it personally as it adds nothing the the actual functionality of my code execution.
Hmmm, sorry if this sounds a bit... >:D
Why should a new feature destroy a community? I even don't think this was the reason for Blitz-Com going down. (is it really down? I don't think so)
Look! I don't like IPhone, I don't like Apple and I even don't like Steve Jobs :P But many GLBasic users enjoy programming for IPhone. So there is no reason for me to speak against it. I just don't want to use it.
So Live and let live :)
No way... it splitt nothing...
GLBasic are one language, and
Blitz3d and BlitzMax are two different languages!
Thats not realy OOP... you just have functions in types not more.
If you don't like it, don't use it ;)
Quotenothing that's there is being taken out. You can continue ploughing on like you used to. Nobody is going to enforce the usage of new functionality upon you.
This is not necessarily true.
QuoteB.t.w. never knew these birds have teeth like that! Courtesy of PhotoShop?
No teeth, but they have powerful beaks and can really hurt you if they grab on to you. Luckily, the ostriches I have been around were quite docile and playful.
Quotewhy - o why did I start that at all...
It's giving me great headaches just to get the basics running again, and there's a wish list that's blowing my mind...
You have opened a gate that can never be closed. Generally, once a language starts moving in the OOP direction, the users will never stop asking for more, as everybody has their own idea of what OOP should be. You will never quit getting requests for new features, changes or improvements on the OOP side.
QuoteI must admit I am a little worried about this, it all seems pretty harmless but the OOP disaster that was the conversion from Blitz3D to BlitMax, destroyed an otherwise vibrant large community.
Indeed, Blitz has never recovered. DarkBasic and PureBasic really saw an influx of Blitz users after BlitzMax was released.
OOP in indie languages almost always is a bad thing because the best industry-leading OOP languages out there are now free. If a language implements OOP features, that is who the competition now becomes. No longer is it an indie language trying to compete against other indie languages, it becomes an indie language trying to compete against VC++, etc and an indie language can never win that fight.
Where indie languages traditionally succeed is when they stick to their roots, stick with a simpler syntax, and target beginners, hobbyists, bedroom coders, and indie developers who are traditionally ignored or overlooked by the mainstream programming languages.
QuoteWho knows, maybe it will be a good thing but I don't see me using it personally as it adds nothing the the actual functionality of my code execution.
It adds unnecessary overhead =D
QuoteIf you don't like it, don't use it
This is one of those things, where you don't have a choice. You have to use it whether you like it or not, unless Gernot is going to keep two versions of the language going :D Just because you do not use a feature, doesn't mean that its code isn't compiled into the EXE. Besides what this may add to the EXE in size, and any effect it may have on speed, will any bugs introduced also affect those not using the new OOP features?
Gernot: Would you consider one last 7.X patch before the new features go in and we jump to 8.0?
QuoteGernot is NOT offering any OOP - he's merely extending TYPEs a bit, to allow better encapsulation.
Yes, encapsulation is a crucial part of OOP, what was your point again? :D
Quotethere's no need to use it if you don't want it or don't like it...
The only way not to use it would be not to use GLB. This isn't platform support, this is something that is a part of GLB whether you use it or not. It can contribute overhead and it can affect EXE size.
QuoteLet's just let Gernot do his thing and see what he comes up with....
Unfortunately, some are not content with this, Gernot has said he doesn't like it, but people keep pushing for it. I call your words an intentional misrepresentation of the facts. =D
Quote from: Kuron on 2010-May-03
The only way not to use it would be not to use GLB
Thats wrong wrong wrong wrong and wrong!
You have NO performance loses with that methods-thing, so the only thing is:
If you don't like it, don't use it!
Quote from: Ocean on 2010-May-03
Right on, SchranzOr ! :enc:
like everytime :D :glare:
Thing is: GLBasic is BASIC. And the main purpose of GLBasic was a) easy to use and b) fast execution.
I'm not making GLBasic more complex. I just add the availability to not only have variables in a type, but also functions that you can call with a type's instance. No static functions, no overloading, no inheritance, no generics.
Instead of:
TYPE Tvec
x;y;z
ENDTYPE
LOCAL a AS Tvec
vec_add(a,a)
FUNCTTION vec_add: a AS Tvec, b AS Tvec
INC a.x, b.x; //...
ENDFUNCTION
you "can" do this:
TYPE Tvec
x;y;z
FUNCTION add: b AS Tvec
INC self.x, b.x
ENDFUNCTION
ENDTYPE
LOCAL a AS Tvec
a.add(a)
Nothing more and nothing less. And you won't convince me to add anything else now. That's really the maximum extend BASIC might go in my head.
Quote from: Schranz0r on 2010-May-03
If you don't like it, don't use it!
Like I said, we don't have a choice, it is in there whether we use it or not :nana:
QuoteAnd you won't convince me to add anything else now.
Good news :nw:
QuoteAnd you won't convince me to add anything else now.
Not even DRAWOVAL/DRAWELLIPSE? ;)
lol. Nothing that extends the language syntax I meant.
Drawoval is no biggie. You can polyvector it yourself if you want:
DrawOval(100,100,99,33,RGB(255,0,0))
SHOWSCREEN
MOUSEWAIT
FUNCTION DrawOval%: x, y, w, h, col%
INC x, w/2
INC y, h/2
LOCAL phi
STARTPOLY -1, 0
POLYVECTOR x,y, 0,0,col
FOR phi = 0 TO 360 STEP 5 // how poly do you want it?
POLYVECTOR x+COS(phi)*w, y-SIN(phi)*h, 0,0,col
NEXT
ENDPOLY
ENDFUNCTION
Yeah, I know Gernot. And that was similar to a method I was using myself anyway.
It just felt like a missing command (it's been in pretty much every other extended BASIC syntax I've used for years). We have DRAWRECT as an internal command, so why not DRAWELLIPSE.
It's nothing major.
Quote from: Ocean on 2010-May-04Most avionics packages (you know, that stuff that runs computers in the plane's front office) is programmed using OO environments (C++ or more often ADA), whether the programmer used it or not....
You seem confused, I actually love OOP. I just do not like seeing GLB lose what makes it unique and doing something just because other languages may do it ;)
Quote from: Kitty Hello on 2010-May-03
TYPE Tvec
x;y;z
FUNCTION add: b AS Tvec
INC self.x, b.x
ENDFUNCTION
ENDTYPE
LOCAL a AS Tvec
a.add(a)
Hmmm.... work this in V8?: (Function without calling itself as parameter?)
TYPE Tvec
x;y;z
FUNCTION create: x, y
self.x = x
self.y = y
ENDFUNCTION
ENDTYPE
LOCAL a AS Tvec
a.create(10,20)
Whooops... simply have to look at the first Post :P
For those who want to test - see the first post.
QuoteGernot is not hunting another programming environment's spec sheet. He's is responding to customer demand
Yes, he is and he is doing it against his better judgment. ;)
Quotethat keeps GLB from becoming a dinosaur one day...
I agree, it would be sad if GLB suffered the same fate as other indie languages that started down the OOP road. Luckily, Gernot has put his foot down, so it is now a moot discussion and we should drop it :)
Will you be able to get this going in debug mode too? Works fine in release mode, but in debug mode it just generates "error: expected constructor, destructor, or type conversion before '(' token".
In addition, will this work with arrays ? I've tried :
TYPE Tvec
x;y;z
FUNCTION null:
self.x = 0; self.y=0; self.z=0
ENDFUNCTION
FUNCTION add: v AS Tvec
INC self.x, v.x
INC self.y, v.y
INC self.z, v.z
WHILE KEY(44)=0
PRINT self.x,0,0
SHOWSCREEN
WEND
ENDFUNCTION
FUNCTION moo%:
ENDFUNCTION
ENDTYPE
LOCAL push AS Tvec
LOCAL test[] AS Tvec
DIM test[0]
push.null()
DIMPUSH test[],push
test[0].moo()
But I just get : "error : call to undefined function : Tvec" with the last line.
update at the beta place. Works for me now.
Same filesize and dates as the previous one - is that correct ?
I think I've found a compiler bug too - it appears that compound strings are messed up (or the compiler doesn't like //). With the following :
ok%=NETWEBGET(proxy$, "http://"+webAddress$+str$, port%, baseData.tempFile$)
The compiler states :
error: expected `)' before ';' token
And the C file is :
ok=NETWEBGET(proxy_Str, CGStr("http:");
:giveup:
TYPE Vec
x;y;z
FUNCTION Create: x, y, z
self.x = x
self.y = y
self.z = z
ENDFUNCTION
FUNCTION Print_Debug$:
PRINT "x = "+self.x+" y = "+self.y+" z = "+self.z, 10,10
ENDFUNCTION
ENDTYPE
LOCAL v AS Vec
vec.Create(10,20,30)
"Methods.gbas"(22) error : call to undefined function : vec
Beta from first post installed...
Shouldn't that be...
v.Create(10,20,30)
Yes, it should be :)
of course it should!
Quote from: MrTAToad on 2010-May-04
ok%=NETWEBGET(proxy$, "http://"+webAddress$+str$, port%, baseData.tempFile$)
And the C file is :
ok=NETWEBGET(proxy_Str, CGStr("http:");
Ah, c'mon. That's not really bad, is it? :P
Oh dear. Now you see why I made this beta. You can't imagine what type of errors I got at the first run... I'll see if I can find time to fix that soon.
OOOOOOOOOOOOOOOOOOOOOpppppps... that was to late yesterday :)
Sorry!
OK, both fixed?
Yey! Arrays are working as is debug mode version :)
One thing that would be more efficient is that, instead of having "self" to access variables in a type, automatically assume that variable access will be done with variable from a type, and use something like "local." or "global." to access local or global variables.
Another thing : A function defined in one type can't have the same name in another type, which is a shame...
In addition, you can't access a TYPE that hasn't already been compiled, which can be a problem if you want to pass a TYPE - you wouldn't all TYPE's in one file...
Aside from these problems, it seems to be working well, aside from the very tricky to diagnose "`__l_dbg_cont' was not declared in this scope" error. At the moment, it seems to be caused by GLOBAL setup AS TSetup (as an example) in the main file or when a standard file is included, which is rather a problem :)
can you make small code pieces for these bugs?
If you need 2 files, just paste the 2nd file below the first - will be the same internally.
The included file will generate the cont error...
[attachment deleted by admin]
With the latest beta, WHILE TRUE generates a Syntax Error on Windows XP, but not Windows 7 :blink:
Fixed now with that updated file...
It does appear the GLOBAL problem only occurs in debug mode...
There does seem to be a problem calling functions from a TYPE, for example :
TYPE TBorder
x%;y%;width%;height%;image%;alpha // For displaying the border
FUNCTION Initialise_Border%:setup AS TSetup
self.x%=0
self.y%=0
self.width%=setup.ReturnHalfScreenWidth()
self.height%=setup.screenHeight%
self.image%=setup.spriteLoadData[0].idNumber%
self.alpha=0.0
ENDFUNCTION
FUNCTION Render_Border%:
ALPHAMODE self.alpha
STRETCHSPRITE self.image%,self.x%,self.y%,self.width%,self.height%
ENDFUNCTION
ENDTYPE
Generates a "call to undefined function : TSetup" error, even though ReturnHalfScreenWidth is present. However, I can access the variables in TSetup okay
A simpler example is :
TYPE TTest
FUNCTION moo%:
ENDFUNCTION
ENDTYPE
GLOBAL test AS TTest
test.moo()
Again, TTest (and TBorder) is in a seperate file. It does look as though, whilst the class/type is being created, no functions are being created in it...
By the way, CODEFILE isn't quite correct :
#define CODEFILE_Str() (DGStr("Test.gbas.gbas"))
Having fun, Gernot :D
For some reason, the following (which is all in the same main file), generates an error (error : wrong argument type : TYPE is not declared) :
TYPE TFont
FUNCTION moo:
ENDFUNCTION
FUNCTION moo2:
RETURN 1
ENDFUNCTION
ENDTYPE
LOCAL font AS TFont
LOCAL big
font.moo()
big = font.moo2()
The problem seems to occur when trying to assign big to the value from moo2 - remove that, and its okay, but unfortunately, is not the desired result.
Here's an interesting article on OOP - http://www.4js.com/en/fichiers/b_genero/pourquoi/Has_OOP_Failed_Sept_2005.pdf
Pretty much agree with it - generally, OOP over-complicates things and can make this much harder to read...
However, extended types in GLBasic however, make things much easier to re-use and update.
Another slight problem found :
It appears function order matters when calling another function :
TYPE TImage
Width
Height
FUNCTION MidHandleImage:
self.SetHandle(self.Width/2,self.Height/2);
ENDFUNCTION
FUNCTION SetHandle:x,y
ENDFUNCTION
ENDTYPE
This generates the usual "call to undefined function : TImage" error message. However, if you put SetHandle before MidHandleImage :
TYPE TImage
Width
Height
FUNCTION SetHandle:x,y
ENDFUNCTION
FUNCTION MidHandleImage:
self.SetHandle(self.Width/2,self.Height/2);
ENDFUNCTION
ENDTYPE
and all is fine...
Great find. I'll try to fix that one, too.
Now, onto different variables in types :
TYPE Ta
a
FUNCTION first%:
a=10.0
ENDFUNCTION
FUNCTION test%:a%
LOCAL b%
b%=a%
ENDFUNCTION
ENDTYPE
With this you get "error : redefinition as different type : a is of type DGInt". Now there is a real "a" and an integer "a%". The problem is that the scope rules are a bit different than usual.
It seems that when b%=a% is performed, the precompiler is checked the a against the a in the TYPE, which it should only be doing if SELF was used.
OHOH :noggin:
you forgot the "self.". It's required!
Thats the problem - in this case, self shouldn't be used as I'm not using a in the TYPE... I want to use the a% variable which would be a passed value.
a%
and self.a should be treated differently (especially as they are different types).
TYPE Ta
a // a# is a member of Ta
// first% is a member function of Ta!
FUNCTION first%:
a=10.0 // a is not declared. A GLOBAL will be created
self.a = 10.0 // a# member var is used now
ENDFUNCTION
FUNCTION test%:a%
LOCAL b%
b%=a% // assign LOCAL a%(Param) to LOCAL b%
ENDFUNCTION
ENDTYPE
Yes, actually I did forget self :)
However, I do think global variables shouldn't interfere with passed variables - its a problem I've met occasionally with V7 :)
Might we worth adding a few descriptive error messages - for example : error: no `DGNat __GLBASIC__::Tb::moo()' member function declared in class `__GLBASIC__::Tb' really means that you've tried to define a TYPE twice...
Indeed - it looks like passed variables are treated as global, hence the message. Unfortunately that can be a bit of a problem at times.
It's not complaining about the passed variable. It's complaining about the variable it had to globally create above. Turn the explicit option on to see where is starts to trouble.
One other thing - with the new type system, the compiler complains if you use INLINE...
Always or just sometimes? Please post an example then. It works for me here.
Its generally all the time :
INLINE
extern "C" char * tmpnam ( char * str );
ENDINLINE
TYPE Ta
FUNCTION moo%:
INLINE
int x,y;
tmpnam(NULL);
ENDINLINE
ENDTYPE
This generates :
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_tempg.cpp:19: error: `tmpnam' was not declared in this scope
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_tempg.cpp: At global scope:
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_tempg.cpp:26: error: expected `}' at end of input
With just :
TYPE Ta
FUNCTION moo%:
INLINE
int x,y;
ENDINLINE
ENDFUNCTION
ENDTYPE
get the usual "error: `__l_dbg_cont' was not declared in this scope" error
PLS use INLINE in a separate GBAS,
also the Type must be in there!
I'm assuming that you would put it the source section and not the main file.
And the type is there :S
hmmm... :noggin:
No doubt the later versions of GPC.EXE fix the problem :)
Oh dear!! The function body is generated in another file (the global definition file), whereas the first inline block goes in the 1st file cpp.
In this case, you can either work with IMPORT or with a function wrapper.
Thanks Gernot, functions in types is the best update for me. This way you can organize the code better and keep all the functions that treat a type in a place. Developers can use this or not, but If you think in objects or types is very useful.
Indeed - they are useful. All that is needed now is the ability (like normal types) to define one extended type and use it in another - its needed so that they dont all have to be put in one file.