[Gambas-user] Static Classes and Modules

[Tobias Boege]

On Sun, 21 Sep 2014, B Bruen wrote:
> On Sat, 20 Sep 2014 10:55:06 +0100
> John Leake <jleake at ...3375...> wrote:
> 
> > Thanks Tobi,
> > >> So could someone tell me if a class without any dynamic variable ie a
> > >> static class, can or cannot be created ?
> > >>
> > > 
> > > Or you can try it out.
> > > 
> > > What I did was creating a module and making objects from it with New -- it
> > > works, but those objects are even more limited than I had expected. In their
> > > code, there seems to be no way to even see that they are any different from
> > > the automatic instance (singleton). The module's code was:
> > > 
> > > --8<--[ Module1.module ]----------------------------------------------------
> > > ' Gambas module file
> > > 
> > > Public Sub Print()
> > >   Print Me
> > > End
> > > --8<------------------------------------------------------------------------
> > > 
> > > and the program:
> > > 
> > > --8<--[ MMain.module ]------------------------------------------------------
> > > ' Gambas module file
> > > 
> > > Public Sub Main()
> > >   Dim h As New Module1, g As New Module1
> > > 
> > >   Print Module1
> > >   Module1.Print()
> > >   Print "---"
> > >   Print h
> > >   h.Print()
> > >   Print "---"
> > >   Print g
> > >   g.Print()
> > > End
> > > --8<------------------------------------------------------------------------
> > > 
> > > with the output:
> > > 
> > >   (Class Module1)
> > >   (Class Module1)
> > >   ---
> > >   (Module 0x...b8)
> > >   (Class Module1)
> > >   ---
> > >   (Module 0x...e8)
> > >   (Class Module1)
> > > 
> > > So indeed, there are different objects (especially, it's possible to
> > > instantiate modules) but "Me" inside the module code always refers to
> > > the singleton.
> > > 
> > This is where I have a problem h and g are different.
> > 
> (Caveat: without knowing how Benoit did it.)
> Because h and g are different. They are pointers to the heap entries for each of those objects. Even if those objects do not have any memory allocated for dynamic variable data (and are therefore "useless" in the sense that they are empty objects not useless in the sense of "incapable of doing anything useful").
> In a class Me will refer to the object address in the "dynamic" heap but in a module Me will refer to the address in the "static" heap. Similarly, anything declared as static in a class will be allocated space in the "static" heap and each of that classes objects will have reference entries for those items that point to the same addresses in the "static" heap.
> Anything declared in a module is assumed to be static, so your  Public Sub Print() is in reality equivalent to Static Public Sub Print() and thus returns the address in the "static" heap.
> 

You are right. The staticness of the function makes Me = AutoInstance seem
correct to me again. Although we shouldn't still be discussing properties of
things that don't exist :-)

> BTW this is slightly different to a singleton, in theory at least.  According to my memory, the singleton "pattern" is used to restrict creation only one instance of a certain class.  That is, there will be only one instance "allowed" in the "dynamic" heap.  The intent was to provide a way to control allocation of resources for the object.  For example, if the program needed a large resource hungry chunk of data, but that data was only used in certain cases of execution, then rather than "always" allocating space for it in the "global" memory area, a singleton class was used which was only instantiated when required (and presumably destroyed when no longer required). So, to my way of thinking, a Gambas module is not the same as a singleton. It will always occupy space when it is loaded, whether or not it is referenced anywhere else in the project.  
> 

A class is loaded when it is first referenced and the automatic instance is
created when it is first needed (i.e. the class name is used like an object),
so you are safe here from unnecessary memory allocations.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk