Classes in PureBasic
Re: Classes in PureBasic
We go round and round...
I vote for procedures in structures
Then they are insulated and private until the structure is used.
I vote for procedures in structures
Then they are insulated and private until the structure is used.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Classes in PureBasic
People emphasize too much on classes and forget that classes come at a cost, especially if you mix stuff like multiple inheritance into the mix.
There are other ways to get modular programming going. (without the complexity...)
@Fred
Maybe we can get this instead:
(similar to the Go language - it has no "classy" oop either)
Where the "(x.Foo)" is the receiver of the procedure.
In the long run this is much more flexible and maybe even more powerful than the "class" thing.
Especially if each include file is a module and therefore each module can have procedures with the same name.
There are other ways to get modular programming going. (without the complexity...)
@Fred
Maybe we can get this instead:
(similar to the Go language - it has no "classy" oop either)
Code: Select all
Module MyMod
Structure Foo
intFoo.i
EndStructure
Procedure.i (x.Foo) Get()
ProcedureReturn x\intFoo
EndProcedure
Procedure (x.Foo) Set(value.i)
x\intFoo = value
EndProcedure
;- main
Global myfoo.Foo
myfoo\Set(123)
PrintN(Str(myfoo\Get()))
In the long run this is much more flexible and maybe even more powerful than the "class" thing.
Especially if each include file is a module and therefore each module can have procedures with the same name.
Last edited by fsw on Mon Feb 04, 2013 7:57 am, edited 2 times in total.
I am to provide the public with beneficial shocks.
Alfred Hitshock
-
- Addict
- Posts: 1443
- Joined: Wed Nov 12, 2008 5:01 pm
- Location: Russia
Re: Classes in PureBasic
Fred, let it be, not OOP, but need of isolation procedures (procedures available from a limited part of the code). Otherwise difficult to develop and support projects. I hope you agree with this?Fred wrote:PureBasic won't be object oriented, period.
This can be a Name Space and (or) procedures within the structure.
+1000000Especially if each include file is a module and therefore each module can have procedures with the same name.
Re: Classes in PureBasic
Namespaces (modules) are planned for code isolation, but it won't be OOP.
Re: Classes in PureBasic
How is it planned?Fred wrote:Namespaces (modules) are planned for code isolation, but it won't be OOP.
Code: Select all
Module GUI
Procedure OpenWindow(..)
EndProcedure
EndModule
GUI\OpenWindow(...)
GUI->OpenWindow(...)
GUI_OpenWindow(...)
GUI#OpenWindow(...)
GUI?OpenWindow(...)
GUI::OpenWindow(...)
Re: Classes in PureBasic
Like that:
GUI_OpenWindow(...)
With an OpenModule/CloseModule to avoid the prefix if you want to.
GUI_OpenWindow(...)
With an OpenModule/CloseModule to avoid the prefix if you want to.
Re: Classes in PureBasic
Like this?Fred wrote:Like that:
GUI_OpenWindow(...)
With an OpenModule/CloseModule to avoid the prefix if you want to.
Code: Select all
Module GUI
Procedure OpenWindow(..)
EndProcedure
EndModule
GUI_OpenWindow(...)
OpenModule GUI
OpenWindow(...)
CloseModule
Re: Classes in PureBasic
It will raise an error if your command name clash (like an user lib), so you will have to use the module prefix.
Re: Classes in PureBasic
Code: Select all
GUI_OpenWindow()
Wouldn't be better to use as separator something currently invalid in a procedure name ? For example GUI::OpenWindow()
Code: Select all
Module GUI
Procedure OpenWindow(..)
EndProcedure
EndModule
GUI::OpenWindow(...) ; call the one defined in the module GUI
OpenModule GUI
OpenWindow(...) ; call the one defined in the module GUI
CloseModule
OpenModule GUI
Other::OpenWindow(...) ; call another OpenWindow from another module
::OpenWindow(...) ; call the implicit module (the only one we have now) hence call the PB OpenWindow
OpenWindow(...) ; call the one defined in the module GUI
OpenScreenWindow(...) ; not defined in the module, call the PB command
CloseModule
Shouldn't be the purpose of modules to avoid the name clashing in the first place ?Fred wrote:It will raise an error if your command name clash (like an user lib), so you will have to use the module prefix.
Shouldn't work the other way around then ?
If I use OpenModule all the procedures I call should be searched in that module first without any collision. If it's defined, I call that one.
If a procedure I call is not defined in the module, then the compiler should look outside the module, that way it would find the usual PB commands.
In case I know I want to call a procedure outside the module that has the same name of one in the module, I should have to specify the target module name in the call or the default "implicit" one using only the special chars "::".
Am I missing something ?
Last edited by luis on Mon Feb 04, 2013 3:00 pm, edited 3 times in total.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
-
- Addict
- Posts: 1443
- Joined: Wed Nov 12, 2008 5:01 pm
- Location: Russia
Re: Classes in PureBasic
Maybe better to do so?Should support nested calls modules.
Code: Select all
Module GUI Extends Wind ; Inheritance module Wind.
Public ; Exported from the module.
Pos.POINT
Procedure OpenWindow(..)
EndProcedure
Private ; No exported from the module.
Structure MyStruct
x.l
EndStructure
Win.RECT
Procedure WindowParam(..)
EndProcedure
EndModule
x.MyStruct ; Error - Private Structure.
OpenModule GUI
Pos\x=0 ; OK.
OpenWindow(..) ; OK
Win\left = 4 ; Error - Private Structure
WindowParam(..) ; Error - Private Procedure.
x.MyStruct ; Error - Private Structure.
CloseModule
Code: Select all
Module GUI
Procedure OpenWindow(..)
EndProcedure
EndModule
Module Event
Procedure EventWindow(..)
EndProcedure
EndModule
OpenModule GUI
OpenWindow(..)
OpenModule Event
EventWindow(..)
CloseModule ; Close Event (default)
CloseModule
Code: Select all
OpenModule GUI
OpenWindow(..)
OpenModule Event
EventWindow(..)
CloseModule GUI
CloseModule Event
Re: Classes in PureBasic
Thanks!Fred wrote:It will raise an error if your command name clash (like an user lib), so you will have to use the module prefix.
Sounds OK, except that "Using Module Danilo" or just "Using Danilo" would be easier to use for end users (that use my inckude)
than "OpenModule Danilo" / "CloseMdule" combination.
Code: Select all
Module Danilo
Procedure New_Window(..)
EndProcedure
EndModule
win1 = Danilo_New_Window(...)
OpenModule Danilo
win2 = New_Window(...)
CloseModule
Code: Select all
Module Danilo
Procedure New_Window(..)
EndProcedure
EndModule
win1 = Danilo_New_Window(...)
Using Module Danilo
; Using Danilo ; alternatively
win2 = New_Window(...)
Last edited by Danilo on Mon Feb 04, 2013 3:10 pm, edited 1 time in total.
Re: Classes in PureBasic
Are you sure ? Don't you see a problem with that ?Danilo wrote: Sounds OK
http://www.purebasic.fr/english/viewtop ... 30#p403130
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: Classes in PureBasic
You don't have to close it, it's not mandatory. It can be useful to be able to unregister a module after use, so that's why it's here.
Re: Classes in PureBasic
It's better than nothing!luis wrote:Are you sure ? Don't you see a problem with that ?Danilo wrote: Sounds OK
http://www.purebasic.fr/english/viewtop ... 30#p403130
Code: Select all
Module DirectX
Procedure New_OpenScreen(..)
EndProcedure
EndModule
Module OpenGL
Procedure New_OpenScreen(..)
EndProcedure
EndModule
OpenModule DirectX ; change to OpenGL to use another implementation
scr = New_OpenScreen(...)
CloseModule
Re: Classes in PureBasic
I miss a feature to protect a function in module. Protected functions only available inside the module block.
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.