Concealing Globals in Classes

[Charles Pegge]

Concealing Globals and Combining Incompatible Programs

Supposing you have 2 programs which you want to combine but they have some global variables and functions which share the same name but are incompatible or even do totally different things. One of these programs would have to be edited to change all the conflicting names, which is a perfect way for bugs to infest previously healthy code.

The solution is to encapsulate each program in a class of its own. No need to edit the existing code - even the globals and constants will be isolated and invisible to the other program.

To make the functions available to the ouside world, all you have to do is create methods for each class then call the functions from the methods.

Fortunatley this is an emergent ability of the o2 class system and only a few tweaks were needed to make this possible.

Oxygen Update: http://community.thinbasic.com/index.php?topic=2517




'----------------------------------------
'USING CLASSES TO ENCAPSULATe PROGRAMS
'- isolation of globals
'- exposing internal function via methods
'========================================


uses "oxygen"
dim src as string

src = "
#basic

global a=0,b=0,c=0

class MARTIAN

global a=1,b=2,c=3 'GLOBALS ISOLATED
sub showABC()
print `
MARTIAN GLOBAL
` str(a) `
` str(b) `
` str(c) `
`
end sub

method show()
showABC
end method

end class

class VENUSIAN

global a=4,b=5,c=6 'GLOBALS ISOLATED

sub showABC()
print `
VENUSIAN GLOBAL
` str(a) `
` str(b) `
` str(c) `
`
end sub

method show()
showABC
end method

end class

sub g_show
print `
EARTH GLOBAL
` str(a) `
` str(b) `
` str(c) `
`
end sub

dim as martian m
dim as venusian v

g_show
m.show
v.show

"

o2_basic src
if len(o2_error) then
msgbox 0, o2_error : stop
end if
o2_exec

[Charles Pegge]

Nesting Classes

But what if the two programs already contain classes? With the ability to support inner classes, you won't need to make any alterations to the existing code. The inner classes of one class are invisible to the rest of the program just as static variables are invisible outside a function that uses them.

Currently classes can be nested down to 32 levels (I can't imagine ever wanting to use more than four :) )




'-------------
'INNER CLASSES
'=============


uses "oxygen","file"
dim src as string

src = "
#basic

class MARTIAN

class body
heads as long
arms as long
legs as long

method move()
print `body moves!`
end method
end class

'THESE ARE GLOBAL TO THE MARTIAN CLASS ONLY

dim as string tab=chr 9
dim as body b

b.heads=2 : b.arms=4 : b.legs=8

method show()
print `
MARTIAN BODY
heads` tab str(b.heads) `
arms` tab str(b.arms ) `
legs` tab str(b.legs ) `
`
b.move

end method

end class


dim as martian m

m.show

"

'file_save ( "t.txt", o2_prep src )
o2_basic src
if len(o2_error) then
msgbox 0, o2_error : stop
end if
o2_exec

[Petr Schreiber]

Hi Charles,

thanks for the update!
I think I will use the global syntax from now as it exactly matches behavior I am used to for private (Ryan) with other OOP languages, no need to use "this." ... ideal :eusadance:


Thank you!,
Petr

[Charles Pegge]

Well thanks for raising the issue Petr,

We still have the conundrum that variable names within the class scope have a higher priority over property names with an invisible this. but I think it will keep things fairly clean, using with..end with blocks where necessary.

If you have anything complicated to do with properties it is often more efficient to transfer the values to simple locals to perform the task - then return the results to the object's properties afterwards. This is because the properties are accessed byref - requiring an extra read cycle each time the property is accessed.

Charles

[Petr Schreiber]

Hi Charles,

did some more tests with class globals and realised they are shared across all instances of same class, is it correct?

[Charles Pegge]

Yes Petr,

This should also be true for equates and macros as well as global variables defined within the class.

Charles

[Petr Schreiber]

Thanks for explanation,

I am used for "private static" term for what class global does, also useful in some cases, although not used so often.
But for "combining programs", as that is what it is for by design, it will work good.

I have no problem with using this for privates, I am only affraid people coming from other languages (PB / C#) will experience some problems when starting to learn O2 OOP model. But if manual will stress enough fact for privates you must use "this.", then I guess it will be ok.


Petr

[Charles Pegge]

I was anticipating this Petr, :)

The globals are subtly different from the static class members, which can be public protected or private. You can use static members just as well.

The globals can only be seen from inside a class method,function or sub or an assignment statement within the class.

However if you have a bunch of inner classes the globals of the outer class will be visible inside all their methods etc. and where there are name conflicts - the globals of the inner class will mask the outer globals.

Charles

[kryton9]

Neat stuff and solution! I am glad Petr is here too to post good questions too to help make it clearer for the rest of us.
O2 is growing in capabilities far beyond what one could have imagined when it first came out. My head spins just trying to
absorb it all. Am following the posts in awe.

[Charles Pegge]

Thanks Kent,

Combining code from previously developed programs is usually very hard work. This should make a big difference.

I also want to create transient functions for use inside functions - so called lambda functions. Using macros is an effective way of doing it. More later :)

Charles