making Subs/Functions private to .tBasicU-file?

[ReneMiner]

I want to create some additional Unit-Files with some subs that should only be accessable to the particular unit-file itself. So I would write for example



Private Sub mySub()
'...
End Sub

but help does not tell anything about keyword Private even though it gets colored blue and capitalized in the script.

So I want to make sure: can just variables be private properties to the unit-file or are subs and functions also allowed?

Can two different unit-files have the same titled private subs/functions also?

And some additional small question:
Can a function call itself (recursive)?

[Michael Clease]

So I want to make sure: can just variables be private properties to the unit-file or are subs and functions also allowed?

Can two different unit-files have the same titled private subs/functions also?

I would say no but Eros will confirm when he gets time.

and this is my answer to your last question(obviously you will need some escape route)

Test()
Stop


Sub test()
Static n As Long

Incr n
MsgBox 0, "N = "+n
If n < 10 Then test()

End Sub

[ErosOlmi]

Rene,

I'm sorry but all thinBasic subs/functions are global. "Private" keyword is reserved for future uses.
What you would need is a sort of NameSpace which is something I'm thinking about since some time.

Regarding recursion, yes, you can recursively call a sub/function. Important is to have a sub/function ...exit strategy

Ciao
Eros

[ReneMiner]

OK, that I can make my function shift some elements until there's enough space to insert a new one is possible. Helps a lot. :)

The "private"- stuff makes me think about some extra-thinbasic-filetype, and I call it "Module" instead of "Unit" in this post now.

So maybe the current unit- and "normal" thinBasic-files are still working as now and forever stay the same, and their contents stays global to keep compatibilty for all the programs we already wrote.
A module could have variables, subs and functions that could be declared Private or Public in any case and to access a modules public member it should be necessary to call it like

result = Module\Function()
or
Module\Sub()
or
Module\Var = X
X=Module\Var

So there would be no more fearing of messing up similar controls from one dialog to another for example - ControlID's could be private to the certain module where they are placed on by default since the modules name has to be part of an outside-call. But I don't know if and how this could be realized.

[Petr Schreiber]

Hi Rene,

the module is already reserved term for DLL...modules, but I support this idea of isolated code units.

I personally prefix my "private" routines with private_, so it alerts the user at least visually:


function private_Something_Action()
end function


To avoid name conflicts at least partially, when I have code unit named unit_Something.tBasicU, I prefix all types and functions with Something_ -> this is basically emulation of the namespace approach:


function Something_DoThis()
end function

function Something_DoThat()
end function



Petr

[ReneMiner]

Sure, I read the comments in the multiple-dialogs example with attention. But it makes the code-lines, especially the ones inside the Unit-File very long, so one has to scroll left and right to read them. I'm more the one stuck to clearly arranged and readable stuff.
The private-scope to modular files, call'em maybe "Subassembly" instead of "Module" would make them multiple-usable without worries of names (as File-Dialogs, Color-Pickers, Loading-routines like "fileformat_IMAGE.tBasicU" etc.)