thinBasic 1.9.xx vaporware

[ErosOlmi]

Things already developed in next version (1.9.16) out in few weeks

Methods inside UDT


Uses "console"


Type tCircle
Radius As Double
lColor As Long


Function getRadius() As Double
Return Me.Radius
End Function


Function getColor() As Double
Return Me.lColor
End Function


Function getArea() As Double
Return Me.Radius * Me.Radius * 3.1416
End Function

End Type


Dim c1 As tCircle


c1.Radius = 10
c1.lColor = Rgb(255, 0, 0)


PrintL "---Circle data---"
PrintL "Radius:", c1.getRadius
PrintL "Color:", c1.getColor
PrintL "Area:", c1.getArea


WaitKey




Things I'm working on (for the next 2 or 3 thinBasic versions):

dynamic numeric arrays inside UDT (also static one, that is global to the same type or extended type)
dynamic string arrays inside UDT (also static one, that is global to the same type or extended type)
private/public properties/methods


Things I will work on:

for each <item> in <array of items>
...
<item> will be a pointer to the current <array of items> item
next
UTF-8 support
some sort of try/catch error handling

[ReneMiner]

wow :D

Does it mean there's no more



Type t_type
X as Long
F as Function
End Type

Function t_Type.F()

End Function


will this (beta-)syntax disappear?

[ErosOlmi]

No, both will remain valid.
I usually try to always keep backward compatibility.

More options more freedom to program as you prefer.

[ReneMiner]

yeah both is fine...

So how will this "For Each ... In ..." work?

I suspect like



Dim X(123) As t_Type

Local vX As t_Type At { Varptr(X(1)) | 0 }

For Each vX In X
' vX is now layover on X(whatever) ?
vX.DoSomething()
Next

'For Each [Local] vX [As t_Type] In X ...?


or some more "pointer-accentuated" ?

[ErosOlmi]

Yes but all automatic.

The idea is that programmers will not declare anything other than the array.
<item> will be automatically created/destroyed and will be valid just inside the for/next.


Dim X(123) As t_Type

For Each vX In X
' vX is now layover on X(whatever) ?
vX.DoSomething()
Next

vX will not exist before for/each loop and will not exist after.
At every for/next iteration vX will transparently be a PTR to the current element of X
When the loop ends, vX will be de-allocated.

[ReneMiner]

sounds good. less typing.

So i will wait for 1.9.16 to appear - current idea is some replacement for visual designer. At the time it creates code for all-in-one files but the problem is- if want to change the dialogs layout, add or move controls there's no way to load the script into the designer and to alter controls.
Visual basic solved this with a separate form-file which describes only the form-layout & placed controls. Now i thought of some way to exclude the layout-stuff & ControlIDs into a separate unit-file that only this data is easy to exchange without havig to re-arrange the whole script.

Probably it'll need some pre-defined base-UDT for UI-dialogs and controls...

currently i can simply add the callback functions name like "cWindow.WinProc" and inside callback place a layover at the pointer stored in dialogs user-slot #1.
So for the above in your first post described syntax: how can i add the callback-functions name then? Will i need to use the old/current syntax here?


Can the callback-function-entry-points be passed to UI-controls on creation as function-Ptr instead of a string containing function-name?
How to request udt-function-pointers for new syntax?

That's why i think of some very first built-in UDT with a function, and it's a callback on top of it:



Type UI_tWindowsControl
hndl As { DWord | Long } ' either hDlg or hCtrl
hParent As { DWord | Long } ' obvious then

Callback Function CBDEFAULT()
End Function
End Type


and all the user has to do is now to Dim his stuff As UI-tWindowsControl or as a type that extends it.
Controls- & Dialogs User-slot 1 has to be used mandatory to hold the pointer of the data-structure - then ME inside callback can be created by "UI-core"?

[ErosOlmi]

Hi René,

I do no think for/each will be by next version.
Next version will have for sure complete TYPE definition inside TYPE/END TYPE including methods.
I think there will be also private/public modification.

Regarding callbacks as type methods ... I tried a lot of possible solutions but not found other way to store ME than using DIALOG USER ptr.
Problem with callbacks is that control of that kind of functions is passed to the operating system in/out and using an interpreted language is not easy to get back info.

Check my example of this in \thinBasic\SampleScripts\OOP\Example_250_cWindow.tbasic
I think it is not bad.
trick is to use the following to set ME:

Dialog Set User hDlg, 1, VarPtr(Me)
and the following to get back ME in callback

Local pMe As cWindow At Dialog_GetUser(CBHNDL, 1)

[Michael Clease]

Things already developed in next version (1.9.16) out in few weeks

Methods inside UDT



Function getRadius() As Double
Return Me.Radius
End Function





I'm loving the new functionality but have a question about the use of "me.radius" wouldn't "this.radius" be a better syntax much like its use in c.

Mike C.

[ErosOlmi]

:D, I like programming language contamination.
Maybe I can add: "this" as alias of "me"
I will see what I can do.

[ReneMiner]

:D, I like programming language contamination.
Maybe I can add: "this" as alias of "me"
I will see what I can do.

and "object" as alias of "type" ? :D :D

[ErosOlmi]

and "object" as alias of "type" ? :D :D

I think I have other ideas for "object" keyword.
It is regarding native COM handling.
But it's too premature at the moment to talk about that
:)

[Petr Schreiber]

I love how ThinBASIC exposes SelectExpression for Select statement.

It would be great to follow this innovative pattern, and have Iteration available inside Foreach.

Imagine this:


long items(5)
for each item in items
item = 2 ^ Iteration
next

' -- Now array contains 2, 4, 8, 16, 32


We could expand further and add IterationBegins and IterationEnds. Useful in cases like:


long items(5) = 1, 2, 3, 4, 5
string myText
for each item in items
myText += item + iif$(not IterationEnds, ",", "")
next

' Produces: myText = "1,2,3,4,5"


The Iteration* helpers would always reflect the current nesting level, so it would work even for nested cycles.

(this would be handy for classic for too).


Petr

[ReneMiner]

the "iterations-counter" within for-next (also classic) is a good suggest. It can help avoid a lot of calculation within the loop and also can tell the current array-elements index in For Each (assumed it's a 1-dimensional, 1-based array).

There is already a keyword "Iterate" used together with "For" only- as far as i'm aware of it. Perhaps could simply combine it with other keywords:



For whatever In|To dontCare

If Iterate Begin Then
' first cycle
ElseIf Iterate End Then
' last cycle
Else
PrintL Iterate Value ' current cycle-number/index
Iterate For 'skip cycle
Endif
'...
Next