Page 3 of 11
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 3:30 pm
by Shield
ts-soft wrote:I miss a feature to protect a function in module. Protected functions only available inside the module block.
+1
And: I hope structures can be nested inside modules too, right?
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 3:34 pm
by Danilo
ts-soft wrote:I miss a feature to protect a function in module. Protected functions only available inside the module block.
Code: Select all
Module DirectX
Private state.l
Procedure New_OpenScreen(..)
SetState(1)
; ...
EndProcedure
Private Procedure SetState(_state)
state = _state
EndProcedure
EndModule
Module OpenGL
Private state.l
Procedure New_OpenScreen(..)
SetState(2)
; ...
EndProcedure
Private Procedure SetState(_state)
state = _state
EndProcedure
EndModule
OpenModule DirectX ; change to OpenGL to use another implementation
scr = New_OpenScreen(...)
SetState(...) ; error: Private function
state = 5 ; error: Private variable
CloseModule

Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 3:38 pm
by luis
Danilo wrote:
It's better than nothing!
I'm not sure.
My problem is Fred said, if I understood correctly from those few words, you can write a procedure beep() in a module MOD, call it from inside your module code with beep() and one day if someone define a proc with the same name within a user lib or maybe (it's not clear) simply in some user code which is using your module this will break your module and you will have to go in and replace the beep() with MOD::beep() (actually, MOD_beep() ... sic).
Shouldn't be exactly the other way around ? You write your module and it's protected from outside influences.
You call beep() from other procedures in your module without worrying about what's happening outside.
Then, if when you write your module you know it will need/depend from another module or library you call that beep with OTHERMOD::Beep() or ::Beep() if it's inside a userlib or if it's a PB command. But in this case you know you WANT to call something that's outside.
All this doesn't sound right to me at all.
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 3:41 pm
by ts-soft
like this:
Code: Select all
Module DirectX
Private Procedure SetState(_state)
...
...
ProcedureReturn result
EndProcedure
Procedure New_OpenScreen(..)
bla = SetState(1)
; ...
EndProcedure
EndModule
OpenModule DirectX ; change to OpenGL to use another implementation
scr = New_OpenScreen(...)
SetState(...) ; error: Private function
CloseModule
And variables should always protected.
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 3:43 pm
by Shield
luis wrote:
Then, if when you write your module you know it will need/depend from another module or library you call that beep with OTHERMOD::Beep() or ::Beep() if it's inside a userlib or if it's a PB command. But in this case you know you WANT to call something that's outside.
Good point! A module should definitely prefer its own functions over external ones.
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 3:53 pm
by User_Russian
ts-soft wrote:I miss a feature to protect a function in module. Protected functions only available inside the module block.
http://www.purebasic.fr/english/viewtop ... 15#p403131
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 4:03 pm
by luis
Tired to never get an answer, so I give up.
Bookmarked my first post about this and we'll see when it will be actually implemented.
Bye guys.
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 5:07 pm
by skywalk
While I welcome the possibility of modules, I already create explicit procedures with:
mynewlib_function1()
mynewlib_function2()
Calling these procedures without some prefix would be very confusing.
If the procedures are inside a structure, I get isolation for free.
mystruc\function1()
And no new keywords to learn

Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 5:50 pm
by c4s
I like your suggestion very much. Would be awesome if this private/public thingy would be implemented too!
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 6:35 pm
by Fred
As you seem interested by the module topic, here is our draft, so you can get a better idea. Please keep in mind than it's no promise, we can drop it if we change our mind so don't expect it for the next version.
Code: Select all
; Here is my suggestion:
; - everything inside a module is "protected" by default. no extra "protected" keyword exists
; - "External" makes something visible on the outside
; - visible items can be accessed as <ModuleName>_<ItemName>
; - OpenModule makes them available without prefix
; - Things like EnableExplicit, EnableAsm, DisableDebugger or OpenModule
; should always be on their default state after a "Module", and be reset
; to what they were at OpenModule after a "EndModule"
;
; So a module is basically totaly separate from compilation outside in terms of naming
; and compiler behavior.
;
;
; As for overwriting names of PB functions: I think we should simply disallow it
; to avoid any possible confusion. The PB functions have very descriptive names (except math maybe),
; so i think it is no problem
;
; About the "all protected by default":
; If you want a list of globals like the IDE "Common.pb", just put that in a module too,
; then any module that wants to use it just has to do "OpenModule Common" and it is done.
; This way we have a good separation and still easy access.
;
; We could have an optional "AllExternal" kind of keyword to define a module where
; everything is externally visible for this purpose:
;
; Module Common AllExternal
; Global A ; no need for an extra "External" keyword
; EndModule
Module Crypto
Global Initialized
#InternalConstant = 128
External #ExternalConstant = 10
Procedure Cipher()
EndProcedure
External Procedure InitCrypto(info)
Initialized = 0
EndProcedure
External Procedure StartCrypto()
Cipher()
EndProcedure
EndModule
OpenModule Crypto
InitCrypto(#ExternalConstant)
StartCrypto()
CloseModule Crypto
Crypto_InitCrypto(#Crypto_ExternalConstant) ; this works also outside
; Example for separation of the explicit state etc:
EnableExplicit
Module Something
; here, EnableExplixit is off, until set otherwise
OpenModule SomethingElse
DisableDebugger
; ...
EndModule
; here, EnableExplicit is on again, the debugger is off and "SomethingElse" is not open
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 6:45 pm
by Shield
Looks promising.

But I still think it should be allowed to redefine PB functions in modules,
for general reasons and those which luis mentioned. What about WinAPI functions?
Structures inside modules?
I think some kind of global access modifier would be great, so if a module defines
a function called Random() we can still use PB's function by writing something like
global\Random(). Same goes for constants: global\#Black.
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 6:50 pm
by PMV
I don't think the unterdline-symbol to split the prefix is a good choise ...
Better is to have something that is not allowed in procedure-names
and somewhere else ...
But the rest is solid and thats what i expected

Very nice!
But still as you mention again ... who knows how many years we
still have until that? I will be glad in any case when it comes.
Would be a good feature for v6.00, wouldn't it?

Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 7:35 pm
by User_Russian
Fred, whether to support the module in module?
Code: Select all
Module Crypto
Module My
EndModule
EndModule
When can we expect the realization this idea? After how many years?
Forum topic for more than 8 years ....

Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 8:37 pm
by fsw
Surely nobody wants that adding things to PureBasic will become a coding nightmare for Fred & Co to get this working right, but also over-complicates things too much for the user.
Now lean back and look at Go's simplicity:
A main file gets this at the top:
A main file can include other files; if they have this at the top:
they are part of the main module.
If you import another module you do:
and a file with this at the top:
gets imported.
Why should PureBasic become more complicated than Go?
It doesn't!
Just exchange "package" with "module" and you're done
peace
Re: Classes in PureBasic
Posted: Mon Feb 04, 2013 8:40 pm
by freak
A few comments from my side:
About the '_' as separator:
One benefit of this choice is that it makes the entire Module feature just "syntactic sugar": The compiler can internally turn a program with modules into a valid PB program with no modules without changing the qualified (module+local) name of any lexical elements. This makes things simpler because other parts of PB (mainly the debugger) do not need to know about modules at all. Introducing a new separator means that these other parts need to be able to deal with modules as well. This is of course not impossible to do, but the '_' method makes it a lot simpler. As Danilo said: It would be a little like With/EndWith: Something that the compiler can resolve early on and then treat the code like an ordinary PB source.
In this concept, the module feature is just an extension of what people are doing already to separate their codes into local parts. I don't think the '_' is any less good in this respect that another separator. There is no confusion between an X_Foo() procedure that belongs to module X and another X_Foo() procedure that you write elsewhere because you can't. They refer to the same thing. The declaration of the second one will result in a duplicate procedure name error. Wouldn't it be more confusing to have an X::Foo() and X_Foo() procedure in the same code and they refer to different things? So if you already try to avoid such confusions then using '_' as the actual separator does not impose a further limit anyway.
Redefining PB functions:
The goal is to encourage writing code that is easy to read and maintain. How is code easy to maintain if you redefine a well known PB function (to which F1 will bring you the PB help) with some custom definition. Its a recipe for problems. PB functions, WinAPI functions and constants are language features and available everywhere. Redefining them is an error. This way you can be sure that OpenWindow() is actually the documented PB function and not something else.
As for somebody writing a userlib with the same command: You have to manually copy a userlib into you PB folder, so its not like this will happen by accident. Besides, PB does not have an official support for creating userlibs from PB code and the ones written in C are not that numerous. Because modules offer the better features for separating names and are essentially "userlibs in source form", we will encourage people to distribute their libs as modules and not libraries in the future.
Finally, PB already has a mechanism that allows redefining PB commands: Macros. If you really need to replace a PB command you can already do it. You don't need Modules for that.
Modules in modules:
I don't see a common need for this. I have a hard time coming up with a useful example for it to be honest. And the semantics of such a feature would be hard to define and understand. Once again: we are trying to keep things understandable and not make them unnecessarily complex.
> When can we expect the realization this idea? After how many years?
> Forum topic for more than 8 years ....
Its not like we did nothing all these years. Look at the release history. What other feature should we have dropped to get the time for this?