Quote from: Theo Gottwald on August 07, 2022, 08:04:42 PM
Charles, the good thing is that we have the direct line to you so small wishes can get full filled.
It was never easy with PB to really get individual wishes fullfilled.
I remember that i asked for "Modules" and got "OBJECTS".
Long Years ago. :-)
I think modules could be very useful for bringing together pieces of code that have been developed separately. It avoids the need to alter conflicting global variables, and provides a level of organization above objects.
update:
General module structure
------------------------
module
interface 'code globally visible
...
inner 'code visible only inside the module
...
end inner
end module
I've posted another update to support modules :)
https://github.com/Charles-Pegge/OxygenBasic/blob/master/OxygenBasic050P1.zip
Charles
what is exactly purpose of this modules ?
I am asking because i don't need it and looks to me like bloating compiler .
But maybe i am wrong ?
tnx
ps .what is latest version without them ?
ps ...nothing to worry
i upload A043, SC 029 and SC 040 to my github
just to prevent lost of version even is still on sourceForge
all best
Modules, being based on existing constructs, only occupy 0.005% of the compiler. So no bloating here :)
Large programs can be split into several modules for redeployment in other projects, without rewriting the code.
A DLL is a kind of module, but this allows multiple modules to be compiled from source into a single binary.
ok that is good !
Hi Charles,
I find it really interesting to use the module.
Is there an example in version 050p1? If so, what is it called?
... thanks again for your work.
Cheers
Hi Nicola,
I have not produced any examples yet. It is quite hard to demonstrate the potential of modules on a small scale.
As I see it, modules are placed at the top of the language structural hierarchy:
program
module
class
procedure
subroutine
block
statement
expression
instruction
Here is on example linking a visible function to an internal function:
========
module X
========
interface
'
!* fi(int a) as int
'
inner
'
function ff(int a) as int
print "ok " a
end function
'
'links
@fi=@ff
'
end inner
'
end module
'
fi(3)
Another example demonstrating how to retrofit a module around existing code, exposing only a few functions:
module
sys p1,p2,p3,p4
inner
============
uses console
============
p1=@input
p2=@output
p3=@cls
p4=@getkey
end inner
! input() as string at p1
! output(string s) at p2
! cls () at p3
! pause() as int at p4
end module
Charles,
it's really interesting. I tried and saw that you can have different outputs and inputs (console or win) with this module.
(Did I get it right? :))
module
sys p1,p2,p3,p4
inner
============
uses console
============
p1=@input
p2=@output
p3=@cls
p4=@getkey
end inner
! input() as string at p1
! output(string s) at p2
! cls () at p3
! pause() as int at p4
end module
string a=input 'input from console
output a 'print in console
print a 'print in wind
output a 'print in console
pause 'wait a key in console.
well it looks like mini sub - program
Hi
Rather than a sub, it creates an environment that can be interfaced with another environment.
Or am I wrong?
Cheers
Yes, with a module you can create an interface for common use and hide the rest of the code, ensuring there are no name conflicts.
An alternative to using inner, would be to put console. inside its own namespace, which would enable access to all parts without a specific interface.
I have just released a new version of o2 with nested namespaces, and one bug fix :)
https://github.com/Charles-Pegge/OxygenBasic/blob/master/OxygenBasic050P2.zip
'modules and namespaces
module console
namespace cn
uses console
end namespace
end module
'reopen the console namespace
'no need for namespace prefixes
namespace cn
print "ok1"
end namespace
'use namesoace prefixes
cn::print "ok2"
cn::getkey
"Nested Namespaces"?
How is it implemented?
Does it mean, that a MODULE "GRAPHICS" could have the Sub-MODULES "SCREENPRINT" and "OUTPUT"?
Now there should be a way that the Sub-Modules can access Variables from their Father Modules.
Then this would be interesting as you could make different Modules with the same name Sub-Modules.
Now Let me ask for "INITIALIZATION" and "DESTRUCTION". This Feature is actually in PB Objects available.
Its often useful for Subprogrammes to have a "One Time Initialization" and have some "De-Allocation" when the Program ends.
Would it make sense to implement this also for MODULES?
Secondly:
In my PB Programming i often have the Problem that during Initialization of Subprogrammes, i need also to initialize Global Variables.
This would also be something that would be interesting if i had inside the MODULE the Options:
1. "MGLOBAL" ..."MENDGLOBAL"
where all the stuff between will be added as "Global declaration". As Alternative to STATIC.
2. "MMAIN" ... "MENDMAIN" where all the stuff between will be added inside the MAIN Procedure at the start of this.
These are to some degree pure Text Processing Options (You take all the stuff in between and move it behind the "GLOBAL or MAIN-Section"
and therefore can easily be added to the MODULE Definition.
Third:
Question, Can Sub-Modules in some way access Variables from their "Father Modules" where they are inside?
If so there could also be a need to treat these as "Global" to these Sub-Modules. Which sounds interesting.
Quote
Does it mean, that a MODULE "GRAPHICS" could have the Sub-MODULES "SCREENPRINT" and "OUTPUT"?
Now there should be a way that the Sub-Modules can access Variables from their Father Modules.
Then this would be interesting as you could make different Modules with the same name Sub-Modules.
With nested namespaces it works the other way round: mothers can access their children. Also, different mothers may name their children the same, but they will be completely different children.
Currently, modules are purely conceptual, and just provide a notional framework.
namespace motherX
namespace childA
...
end namespace
namespace childB
...
end namespace
...
end namespace
namespace motherY
namespace childA
...
end namespace
namespace childB
...
end namespace
...
end namespace
Quote
Now Let me ask for "INITIALIZATION" and "DESTRUCTION". This Feature is actually in PB Objects available.
Its often useful for Subprogrammes to have a "One Time Initialization" and have some "De-Allocation" when the Program ends.
Would it make sense to implement this also for MODULES?
Quote
Secondly:
In my PB Programming i often have the Problem that during Initialization of Subprogrammes, i need also to initialize Global Variables.
This would also be something that would be interesting if i had inside the MODULE the Options:
1. "MGLOBAL" ..."MENDGLOBAL"
where all the stuff between will be added as "Global declaration". As Alternative to STATIC.
2. "MMAIN" ... "MENDMAIN" where all the stuff between will be added inside the MAIN Procedure at the start of this.
These are to some degree pure Text Processing Options (You take all the stuff in between and move it behind the "GLOBAL or MAIN-Section"
and therefore can easily be added to the MODULE Definition.
namespaced global code is executed
inline as any other global code, so initializing is simply a matter of assigning values. If destructors are required then you can provide destructor procedures for each namespace. Mother destructors can invoke their child destructors, so it is easy to cascade the destruction process.
namespace motherX
namespace childA
'init
int a=100
'
sub destructor()
...
end sub
'
end namespace
'
namespace childB
'init
int a=200
'
sub destructor()
a=0
end sub
'
end namespace
'
'init
int b=1000
'
...
'
sub destructor()
b=0
namespace childA
destructor()
end namespace
namespace childB
destructor()
end namespace
end sub
end namespace
The way that you can access everything "down the line" sounds good.
From the implementation you say its a "textual implementation"?
Thats the fastest way to do it.
Then a child can not find out who is his mother?
Maybe you can find a way around this using some sort of "ME." Like in Powebasic?
For example:
LOCAL XY AS ??
XY=MyMother()
Then I could access variables from my parent using
A=XY.Varname
Should be easy doing if its textual implemented.
While Encapsulation is necessary to build "Building Blocks" for later use (reusable code),
there are often use cases where you need to break the hull.
For example if you want to make child-constructs that are universal for different parents.
Possibly a Variable could even be declared as
LOCAL A as Mother
Then you can simply use it as
A.Varname
to access Parents Variables.
Hi Theo,
re: namespace
I wanted to keep modules and namespaces as separate concepts. A module may or may not use namespaces.
namespace is widely understood, but the C++ ;; notation does not sit well with Basic, I agree. We could use double-dots instead. Unfortunately, single-dots would be too confusing when we have both nested namespaces and nested UDT members!
With nested namespaces, it becomes necessary to distinguish absolute names from relative names . This can be done by prefixing the relative child names with double-dots.
It would also be possible to reference parental symbols using a triple-dot prefix.
However, to ensure modular independence, I still think it is a design error for a nested child to know anything about its parental symbols. If any mode-setting or any i/o is required, the parent should be the actor.
Illustrating the use of relative namespace expressions, encapsulating console.inc in a module:
==============
module console
==============
namespace cn
uses console
end namespace
'
interface
---------
'relative namespaces with prefixed ..
$ cprint ..cn..output
$ cwait ..cn..getkey
$ tab ..cn..tab
$ cr ..cn..cr
end module
'
cprint 12345 tab "okay" cr
cwait
Update:
https://github.com/Charles-Pegge/OxygenBasic/blob/master/OxygenBasic050P3.zip
I've found a way to use macros (equates) as prefixes.
So namespaces-refs can be consolidated into a single dotted word.
$ cns ..cn.. 'prefix macro
cns.output( )
'with macro prefixes
'
==============
module console
==============
namespace cn
uses console
end namespace
'
$ cns ..cn.. 'prefix macro
'
end module
'
cns.output 12345 cns.tab "okay" cns.cr
cns.getkey
Access to the parent module is now possible. I might be better to consider the inner-modules as servers, and the outer-modules as clients of the inner modules.
We can use a macro to define the client prefix, a triple dot
$ client ...
then refer to any client symbol, such as x
client.x
'with macro prefixes
'Accessing parent / client symbols
'
$ client ...
int x=0
print client.x '0
namespace aa
int x=2
print client.x '0
namespace bb
int x=4
print client.x '2
namespace cc
int x=6
print client.x '4
end namespace
'print ..cc..x '6
end namespace
end namespace
Update:
https://github.com/Charles-Pegge/OxygenBasic/blob/master/OxygenBasic050P3.zip
It's already in OxygenBasic050P6.zip, I don't know what modifications it had, but in my opinion for general use oxygen lacks few details to make it easier for people who just want to program a few functions.
an "IDE" easy to install and with good tools, and arrays without having to use macros
with that it would be enough for most people with more basic usage.
And as I said before, on the other forum, not everyone needs top-of-the-line tools, sometimes you just want to assemble simple things quickly and easily, and oxygen allows that.
but it has to facilitate the use of people who are starting and just want that, ease.
with more people using it, more interested people will appear, even people with more capacity to contribute.
Quotean "IDE" easy to install and with good tools, and arrays without having to use macros
well ...o2 already have "IDE" or editor..s
OXIDE ..by Charles
AurelEdit by ME
and O2H_Edit by Arnold (i think)
i know that my editor is not "the best" and is not featured with things but work well
and is written in o2
for arrays...o2 arrays work well ..what you mean under macros ..i don't have a clue
Quote from: Charles Pegge on August 30, 2022, 07:11:06 PM
I've found a way to use macros (equates) as prefixes.
So namespaces-refs can be consolidated into a single dotted word.
$ cns ..cn.. 'prefix macro
cns.output( )
'with macro prefixes
'
==============
module console
==============
namespace cn
uses console
end namespace
'
$ cns ..cn.. 'prefix macro
'
end module
'
cns.output 12345 cns.tab "okay" cns.cr
cns.getkey
Access to the parent module is now possible. I might be better to consider the inner-modules as servers, and the outer-modules as clients of the inner modules.
Hi,
with P12 it returns error on the 4th line to the name "console". If I take this off and just leave "Module" it works.
But what if I want to put more modules?
Hi Charles, glad to see you are still alive .. I am looking for an old example you have done some years ago UI tbgl oxygen you have built with Pete for thin basic oxygen forum did you create this example for oxygen complete too? Would be great to have some reply.. I am looking for an opengl example with controls like Buttons etcpp best regards Frank