Next version will allow you to omit the 'self.' and the [] array indicators.
Here's a test example, that already compiles:
TYPE T1
i1%
ENDTYPE
TYPE TT
ia[] AS T1
ka[]
FUNCTION foo:
ALIAS p AS self.ia[0]
ENDFUNCTION
ENDTYPE
FUNCTION foo: bar[]
LOCAL t AS TT
FOREACH a IN t.ia[]; a.i1=0; NEXT
FOREACH a IN t.ia ; a.i1=0; NEXT
LOCAL a$[]
FOREACH b$ IN a$[]; b$="X"; NEXT
FOREACH b$ IN a$ ; b$="X"; NEXT
// [] [] omited
t.ia[] = t.ia[]
t.ia = t.ia
foo(t.ka[])
foo(t.ka )
ENDFUNCTION
Very handy and cleaner looking, thanks Gernot! :good:
is it backward compat?
Yes, sure. There are cases when the "self." is still required, but I try to fix that, too. It's just easier to type and most of the time redundant.
Maybe i'm blind but, in function foo you use self.ia[].
So if i understand it right, i can do with the next Update this:
FUNCTION foo:
ALIAS p AS ia[0]
ENDFUNCTION
I haven´t installed GLBasic a year.
Any news, any new features in the next time?
@Schranz0r, yes. I you can omit "self." and "[]" if the compiler clearly knows what you mean.
Thats a nice little improvement :)
Everything that makes a language less verbose is a great improvement. I hate "bloat".
I actually have no idea what this is about. Even reading the examples. :(
In the Type-Methods you can call a Membervariable without a "self." call.
Arrays can do this: Array1[] = Array2[] -> shorter: Array1 = Array2 (No need to write the [])
ah! got it! :good:
Quote from: Kitty Hello on 2020-Oct-17
Next version will allow you to omit the 'self.' and the [] array indicators.
Here's a test example, that already compiles:
TYPE T1
i1%
ENDTYPE
TYPE TT
ia[] AS T1
ka[]
FUNCTION foo:
ALIAS p AS self.ia[0]
ENDFUNCTION
ENDTYPE
FUNCTION foo: bar[]
LOCAL t AS TT
FOREACH a IN t.ia[]; a.i1=0; NEXT
FOREACH a IN t.ia ; a.i1=0; NEXT
LOCAL a$[]
FOREACH b$ IN a$[]; b$="X"; NEXT
FOREACH b$ IN a$ ; b$="X"; NEXT
// [] [] omited
t.ia[] = t.ia[]
t.ia = t.ia
foo(t.ka[])
foo(t.ka )
ENDFUNCTION
I've been thinking about this and I'm not sure I think its a good idea. Maybe I've got it wrong. But in longer listings this could be confusing to read, what variables are sourced from where. I think a better idea would a shorthand option for "self." say just a point ".". So "self.myVar" would become ".myVar". The precompiler would simply check for variables beginning with "."?
in C++, some call the member variables of a TYPE (class in C++) with a 'm_' prefix. The just ".2 prefix might be good, but I hesitate touching this piece of code.
I uploaded to the branch as Beta. Can someone confirm it's all working?
Quote from: Kitty Hello on 2020-Nov-21
in C++, some call the member variables of a TYPE (class in C++) with a 'm_' prefix. The just ".2 prefix might be good, but I hesitate touching this piece of code.
I uploaded to the branch as Beta. Can someone confirm it's all working?
I don't get back till tonight Gernot, I'll try it out when I do.
Phew, quick try of my own game source produced the following error...
FOREACH w IN self.w[]
IF name$=w.text$[WB_NAME_STRING] THEN RETURN i%
INC i%
NEXT
"gui.gbas"(1685) error : GPC0007 wrong argument type on line... FOREACH w IN self.w[]
TYPE TX
text$[]
ENDTYPE
TYPE TT
w[] AS TX
FUNCTION foo:
FOREACH w IN self.w[]
IF "x"=w.text$[0] THEN RETURN
NEXT
ENDFUNCTION
ENDTYPE
This works for me, so can you make a short complete example that does not work?
Quote from: Kitty Hello on 2020-Nov-24
TYPE TX
text$[]
ENDTYPE
TYPE TT
w[] AS TX
FUNCTION foo:
FOREACH w IN self.w[]
IF "x"=w.text$[0] THEN RETURN
NEXT
ENDFUNCTION
ENDTYPE
This works for me, so can you make a short complete example that does not work?
I added... "LOCAL i%, w AS TX" to be more like my original source, it now reproduces the error standalone.
TYPE TX
text$[]
ENDTYPE
TYPE TT
w[] AS TX
FUNCTION foo:
LOCAL i%, w AS TX
FOREACH w IN self.w[]
IF "x"=w.text$[0] THEN RETURN
NEXT
ENDFUNCTION
ENDTYPEAlso, I just pasted this to the end of the file for reference ...
FUNCTION GetWidgetID%: name$
IF name$="" THEN RETURN -1
LOCAL i%, w AS TWidget
FOREACH w IN self.w[]
IF name$=w.text$[WB_NAME_STRING] THEN RETURN i%
INC i%
NEXT
RETURN -1
ENDFUNCTIONHighlighted the code and pressed CTRL+K to block remark it and the IDE crashed and exited to desktop. I Think it has something to do with the final line not having a carriage return. I redid it again but made sure I pressed enter after the last line, then it didn't crash when I remarked it.
Good find on the IDE. The compiler issue is harder. Can you redesign this piece of code, please =D
Quote from: Kitty Hello on 2020-Nov-26
Good find on the IDE. The compiler issue is harder. Can you redesign this piece of code, please =D
I could.. but sometimes I reuse a variable within a block of code, so its not always viable to simply remove the declaration. eg. You will notice I've used the variable "m" twice here, on both occasions its a single type that represents a single material, so logically it makes sense. I could code around it with different variable names but isn't this coding around backwards compatibility?
Actually looking at my game code, I do this quite a lot unfortunately. :'(
Gernot my opinion is this, this is just a "quality of life" improvement, my opinion is not to spend too much time on it if its causing you grief. By this stage I think every one had gotten used to self. anyways! :good:
FUNCTION ReadFile: filename$
LOCAL f%,l$
LOCAL n%,t$[]
LOCAL i%
LOCAL m AS TMaterial
self.Destroy()
self.SetUp()
f%=GENFILE()
OPENFILE(f%, filename$, TRUE)
//DEBUG "Start read TMaterials.ReadFile("+filename$+") file >\n"
REPEAT
READLINE f%, l$
n%=SPLITSTR(l$,t$[]," ")
IF LEN(t$[])=0 THEN CONTINUE
SELECT t$[0]
CASE "newmtl"
DIMPUSH self.m[], m
self.m[-1].name$=t$[1]
CASE "Kd"
self.m[-1].red# = t$[1]; self.m[-1].green# = t$[2]; self.m[-1].blue# = t$[3]
CASE "Tr"
self.m[-1].alpha# = t$[1]
CASE "Ns"
self.m[-1].size# = t$[1]
CASE "#"
DEFAULT
ENDSELECT
UNTIL ENDOFFILE(f%)
FOREACH m IN self.m[]
m.combined% = ASL((m.alpha#)*255,24)+ASL(m.blue#*255,16)+ASL(m.green#*255,8) + m.red#*255
NEXT
//DEBUG "< End read material file\n"
CLOSEFILE f%
ENDFUNCTION
I changed the offending code in this routine...
FOREACH m IN self.m[]
m.combined% = ASL((m.alpha#)*255,24)+ASL(m.blue#*255,16)+ASL(m.green#*255,8) + m.red#*255
NEXT
to...
FOREACH mat IN self.m[]
mat.combined% = ASL((mat.alpha#)*255,24)+ASL(mat.blue#*255,16)+ASL(mat.green#*255,8) + mat.red#*255
NEXT
...but still got eh error "error : GPC0007 wrong argument type" at the FOREACH line, even though I changed "m" to "mat", only within these lines?!?!
OK, I'll quite the possibility to drop the "self.". I'm sorry.
No worries Gernot, thanks for giving it a go. :booze:
Yep, thanks for the efforts! Anything you feel could help will always be appreciated.
The biggest thing for me would be GLOBALS will show up on any gbas-File in the autocompletion.
Thats a "bug" thats drivin me crazy for years now.
New improvements in IDE and language features are welcome, also nice to see some fixes for few bugs, yet from what I've checked that bug with loading images from ShoeBox wasn't fixed :/ I hope that this also will come in proper update ;-) I mentioned that bug here (https://www.glbasic.com/forum/index.php?topic=11411.0)
Get the beta branch. The Shoebox bug is fixed. You need to recreate the SBX files, though.
how do you access the debug branch?
Thanks for looking into it but there is still some issue, check my post in that bug topic.
In Logfile update list I saw that HTML5 platform was added, was it updated to latest emscripten or need some old version is still needed or something? As it was already in this topis (https://www.glbasic.com/forum/index.php?topic=11364.0) there were serious issues with previously available version.
Qedo: find GLBasic on Your Steam Library list, right click - Properties - Betas and there select beta builds :-) from what I see standard version also was updated.
thanks dreamerman you are always kind and helpful :booze:
Ad maiora
Looks like the test modifications that I tested above(see my posts regarding the removing ".self" compiler modification in Steam beta) have now made there way in the the the actual newly updated Steam version of GLB!?!? See... https://www.glbasic.com/forum/index.php?topic=11453.msg101179#msg101179 above.
I now simply cant compile my code. I tried to modify around this error but my project is over 150 thousand lines of code, spread across 129 files... and gave up after an hour.
Obviously this was compiling fine before the update.
"gui.gbas"(1685) error : GPC0007 wrong argument type
FUNCTION GetWidgetID%: name$
IF name$="" THEN RETURN -1
LOCAL i%, w AS TWidget
FOREACH w IN self.w[]
IF name$=w.text$[WB_NAME_STRING] THEN RETURN i%
INC i%
NEXT
RETURN -1
ENDFUNCTION
Its the same piece of code that was tested above after the test modification was made to the Steam beta compiler, which was supposed to be dropped for causing these errors.
I replied in the bug-reports. Get the latest beta, it should be fixed.