skywalk wrote:Hi Boris,
I agree with you, but your postings do nothing to affirm your "classy" statements.
They might as well be written in another language if they don't compile.
Obviously, my sample class does compile, but only as part of a greater class and with the benefit of 114 macros that hide the clutter of PB's syntax.
The point of the exercise was to show the general structure of a class and to show that classes can be implemented. The point was not to show how to do it, since anyone who knows what a class is can put together the elements in a couple of days. And those who don't know what a class is should do some reading first. After which, they too could put together the elements in a couple of days.
For ten years Caesar ruled with an iron hand, then with a wooden foot, and finally with a piece of string.
~ Spike Milligan
No disrespect intended as I did say I agree with your statements.
But, it would be helpful if you prefix such code posts with "non-working snippet".
Best not to assume the experience level of your audience.
I've written several thousand lines of code that "writes" code.
But, posting the preprocessed syntax would be meaningless without the preprocessor itself.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
skywalk wrote:But, posting the preprocessed syntax would be meaningless without the preprocessor itself.
The example that I posted was real PB code, ready to be compiled -- no preprocessing required. It demonstrates how PB can be used to create structured, readable, OOP code.
Implementation is left as an exercise for the reader.
For ten years Caesar ruled with an iron hand, then with a wooden foot, and finally with a piece of string.
~ Spike Milligan
Btw, another reason for the '_': #MyConstant inside Module Foo becomes "#Foo_MyConstant" which looks good. "Foo::#MyConstant" or "#Foo::MyConstant" are both a bit weird imho
Hm, already forgot reason why '_' was mercylessely kicked by dev team (inculding you) from role of line continuator ? No way:
Module _ ; Show me any rule to not do it ?
External __.a ; Show me any rule to not do it ? x2
EndModule
Module __ ; Show me any rule to not do it ? x3
External _.a ; Show me any rule to not do it ? x4
EndModule
Debug ____ ; Where is thine God now ?
Module Engine
Public Procedure Start(...)
EndProcedure
Public Module Terrain
Public Procedure Create(...)
EndProcedure
EndModule
EndModule
ImportModule Engine
Engine.Start(...)
Engine.Terrain.Create(...)
I think that using _ for the scope is just irritating as it may look the function like a globally defined one, just with a prefix added. So this would be just a kind of "semantic" implementation but I think we need a proper syntax for the modules in order to be able to distinguish between a module function call and a normal function call.
Forge wrote:I think that using _ for the scope is just irritating as it may look the function like a globally defined one.......
I agree.
We use "_" in constant names, so if PB uses "_" in namespace references there is always the risk of name conflicts.
FreeBasic implements namespaces in a way that is very similar to the "With" statement, and uses the "." notation for referencing data and procedures. There is a description in the FreeBasic user manual.
A FreeBasic namespace does not represent a "black box" like a class or DLL, but is strictly a method of grouping related data and procedures without the need to prefix the names with a unique identifier. All data and procedures not in a namespace are assumed to be in an unnamed global namespace.
For ten years Caesar ruled with an iron hand, then with a wooden foot, and finally with a piece of string.
~ Spike Milligan
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.