[Gambas-user] Static Classes and Modules

John Leake jleake at ...3375...
Sat Sep 20 23:02:09 CEST 2014


Hi,

Sorry if I have mislead you wrt singletons.  I am doing some experiments
with singletons not using modules as singletons.

I have a problem with consistency. The docs say one thing whereas in
reality something different is happening.  A static class/module either
should or should not be creatable, who knows ? But for goodness sake be
consistent.

Why should a user be exposed to underlying detail of where objects are
created ?

If you can create static classes or modules and the rules say there can
only be one of them (ie they cannot be instantiated more than once) then
from the outside they should be indistinguishable from each other.  If
the language allows you probe deeper (like obtaining the address of the
object) then the results returned should be the same.

On 20/09/14 19:49, 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.
> 
> 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.  
> 
> Anyway...
> regards
> 




More information about the User mailing list