What is your opinion on Global Objects?

What is your opinion on Global Objects?

[Hubert]

This is not an Ada matter per se, but since I see such a vigorous 
discussion about the OOP topic in this forum I thought I'd ask this 
question here which has kept me thinking for a while and I wasn't able 
to find a satisfying canonical statement on this. Some say this and 
others say that, so I think I'd ask for opinions here so that perhaps I 
can form my own at the end.

Here is the question. Assume you have a large software system. Let's 
take the system for instance that I am involved in now as part of my 
work which is a multiplayer Client Server game. It is written in C++ but 
that shouldn't matter for the purpose of this topic.

There are "entities" on the server side that need to be accessed nearly 
everywhere. These entities best fit the Singleton Pattern because there 
is really only one instance of them, ever. For instance the class that 
handles the internet access and all client connections. Or the Ram based 
database that holds all the game objects. There is also the 
representation of the 3D world on the server side which is used for 
position check and all sort of 3D information.

These entities must be accessible from many locations in the code, 
although the region where access is needed can be somewhat restricted 
for instance the internet channel must be accessible for all player 
initiated actions but also by the User Agents that handle open windows 
on the player client and so on.

So my question is basically, is it OK to make these entities available 
through global access variables, or should they all be passed as 
arguments to function calls? We all know global objects are bad (not to 
mention that theorists heftily denounce the Singleton Pattern as bad, 
but, hey there is only one way to the internet and only one database, 
I'm sorry) but we also know that it is bad to carry "tramp data" through 
multiple levels of function calls when the functions do nothing with 
that data but pass it on to lower functions.

Global access can not really be tested in unit tests because they can 
not be passed as parameters. That's my greatest objection with the 
global concept but I dont want to pass 3, 4 or 5 parameters to every 
single function because a function called 5 levels below that call level 
might need access to those objects.

I don't think there is a silver bullet here but I would really love to 
hear what others think about this problem, specifically in an 
environment and with the examples I have shown here.

Thanks

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: What is your opinion on Global Objects?

[Jeffrey Carter]

On 11/17/2014 06:36 PM, Hubert wrote:
> 
> So my question is basically, is it OK to make these entities available through
> global access variables, or should they all be passed as arguments to function
> calls? We all know global objects are bad (not to mention that theorists heftily
> denounce the Singleton Pattern as bad, but, hey there is only one way to the
> internet and only one database, I'm sorry) but we also know that it is bad to
> carry "tramp data" through multiple levels of function calls when the functions
> do nothing with that data but pass it on to lower functions.

This is only a problem in poorly designed languages. In Ada these "singletons"
should be packages. No global variables needed. No access types needed, much
less global access variables.

-- 
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65

Re: What is your opinion on Global Objects?

[Hubert]

> This is only a problem in poorly designed languages. In Ada these "singletons"
> should be packages. No global variables needed. No access types needed, much
> less global access variables.
>
Perhaps I didn't make myself clear enough. I am talking about something like

class A
{
	void function1();
	......
}

A s_object_a;


and then other code being able to access the object like
s_object.a.function1();

I guess in Ada you could have a package with a type and a variable in 
the body but you would still need a way to access that variable somehow 
in other packages, either through a parameter or globally and that's my 
question. What is the best way to access such an object


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: What is your opinion on Global Objects?

[Shark8]

On 17-Nov-14 20:08, Hubert wrote:
> I guess in Ada you could have a package with a type and a variable in
> the body but you would still need a way to access that variable somehow
> in other packages, either through a parameter or globally and that's my
> question. What is the best way to access such an object

Generics?
You could have everything that depends on that singleton have its 
package (or accessor-function) passed in as a parameter.

Re: What is your opinion on Global Objects?

[Jeffrey Carter]

On 11/17/2014 08:08 PM, Hubert wrote:
>>
> Perhaps I didn't make myself clear enough. I am talking about something like
> 
> class A
> {
>     void function1();
>     ......
> }
> 
> A s_object_a;
> 
> 
> and then other code being able to access the object like
> s_object.a.function1();

That may be necessary in C++, but not in Ada.

> I guess in Ada you could have a package with a type and a variable in the body
> but you would still need a way to access that variable somehow in other
> packages, either through a parameter or globally and that's my question. What is
> the best way to access such an object

Through the operations exported by the package. This is a very common Ada paradigm.

-- 
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65

Re: What is your opinion on Global Objects?

[Dmitry A. Kazakov]

On Mon, 17 Nov 2014 17:36:44 -0800, Hubert wrote:

[...]
> So my question is basically, is it OK to make these entities available 
> through global access variables, or should they all be passed as 
> arguments to function calls?

You would have some "Context" or "World" object and pass it along.

> We all know global objects are bad (not to 
> mention that theorists heftily denounce the Singleton Pattern as bad,

Yes, if misused for unrelated purposes, like module initialization etc.

And I doubt that "World" object is really a singleton. It is always better
to expose all stateful parameters rather than hiding them. E.g.

   Put_Line (Standard_Output, ...);

vs.

   Put_Line (...);

Later you might decide to use a different file for the output.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is your opinion on Global Objects?

[Brian Drummond]

On Mon, 17 Nov 2014 19:08:03 -0800, Hubert wrote:

>> This is only a problem in poorly designed languages. In Ada these
>> "singletons"
>> should be packages. 

>  What is the best way to access such an object

Through the accessor subprograms supplied by the package.

- Brian

Re: What is your opinion on Global Objects?

[Hubert]

On 11/18/2014 3:23 AM, Brian Drummond wrote:
> On Mon, 17 Nov 2014 19:08:03 -0800, Hubert wrote:
>
>>> This is only a problem in poorly designed languages. In Ada these
>>> "singletons"
>>> should be packages.
>
>>   What is the best way to access such an object
>
> Through the accessor subprograms supplied by the package.
>
> - Brian
>
That basically is a vote for global objects. Whether they are accessed 
through a global variable or some sort of getter function that returns 
access, it means bypassing the parameters. Well from what I read here, 
there are no strong opinions for either concept. Strange, I wasn't able 
to find good arguments for or against the two concepts anywhere, I guess 
they are just used interchangeably in applications.

Personally I am for global objects since they keep the interfaces 
smaller and avoid tramp data, the problem I see is just the unit test 
setup. Subprograms with side effect are hard to test automatically


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: What is your opinion on Global Objects?

[Jeffrey Carter]

On 11/18/2014 07:50 PM, Hubert wrote:
> That basically is a vote for global objects. Whether they are accessed through a
> global variable or some sort of getter function that returns access

Most of us on here are talking about how to do it in Ada. However you do it in
C++ will be different, because C++ lacks modules. In Ada, there would be no
functions that return access.

At some point you have some requirements for your game, and somewhere in them is
something along the lines of "the game will keep track of this, that, and the
other".

In the design you make from these reqs you decide to meet this req with a DB
object. It allows you to add new (Key, Value) pairs, update the value for a key,
retrieve the value for a key, and delete the pair for a key.

In the Ada implementation, you implement this object as a package:

package Game.DB is
   procedure Add (Key : in Key_Value; Value : in Data_Value);

   procedure Update (Key : in Key_Value; Value : in Data_Value);

   function Value (Key : in Key_Value) return Data_Value;

   procedure Delete (Key : in Key_Value);
end Game.DB;

[I'm sure the reality is more complicated. No doubt there are many different
kinds of (Key, Value) pairs.]

This pkg would be part of a low-level layer in your S/W architecture. Anything
in higher layers that needs to access the DB can with the pkg and call its
subprograms.

This is the "Package as Object" pattern in Ada.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail
04

Re: What is your opinion on Global Objects?

[Hubert]

On 11/18/2014 19:03 PM, Jeffrey Carter wrote:
> On 11/18/2014 07:50 PM, Hubert wrote:
>> That basically is a vote for global objects. Whether they are accessed through a
>> global variable or some sort of getter function that returns access
>
> Most of us on here are talking about how to do it in Ada. However you do it in
> C++ will be different, because C++ lacks modules. In Ada, there would be no
> functions that return access.
>
> At some point you have some requirements for your game, and somewhere in them is
> something along the lines of "the game will keep track of this, that, and the
> other".
>
> In the design you make from these reqs you decide to meet this req with a DB
> object. It allows you to add new (Key, Value) pairs, update the value for a key,
> retrieve the value for a key, and delete the pair for a key.
>
> In the Ada implementation, you implement this object as a package:
>
> package Game.DB is
>     procedure Add (Key : in Key_Value; Value : in Data_Value);
>
>     procedure Update (Key : in Key_Value; Value : in Data_Value);
>
>     function Value (Key : in Key_Value) return Data_Value;
>
>     procedure Delete (Key : in Key_Value);
> end Game.DB;
>
> [I'm sure the reality is more complicated. No doubt there are many different
> kinds of (Key, Value) pairs.]
>
> This pkg would be part of a low-level layer in your S/W architecture. Anything
> in higher layers that needs to access the DB can with the pkg and call its
> subprograms.
>
> This is the "Package as Object" pattern in Ada.
>

Ok this is still an access of the global object directly from a 
subprogram. The subprogram then accesses the variable with the data 
ijnternally which is the same as accessing a global object. The data 
object itself is not passed through the parameters of the subprogram 
that uses it.

Sounds like most people are in favor of that method


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: What is your opinion on Global Objects?

[Jacob Sparre Andersen]

Jeffrey Carter wrote:

> This is only a problem in poorly designed languages. In Ada these
> "singletons" should be packages.

A simple, untested example:

package Counter is
   procedure Reset;
   procedure Increment;
   function Value return Natural;
end Counter;

package body Counter is
   State : Natural := 0;

   procedure Reset is
   begin
      State := 0;
   end Reset;

   procedure Increment is
   begin
      State := State + 1;
   end Increment;

   function Value return Natural is
   begin
      return State;
   end Value;
end Counter;

Greetings,

Jacob
-- 
Photo of the day:
                    http://billeder.sparre-andersen.dk/dagens/2014-11-10

Re: What is your opinion on Global Objects?

[J-P. Rosen]

Le 19/11/2014 10:13, Hubert a écrit :
> Ok this is still an access of the global object directly from a
> subprogram. The subprogram then accesses the variable with the data
> ijnternally which is the same as accessing a global object. The data
> object itself is not passed through the parameters of the subprogram
> that uses it.
<Plug>
Note that AdaControl (rule Directly_Accessed_Globals) can enforce that
this pattern is used safely. From the User's Guide:

"this rule enforces that all global variables are accessed by dedicated
access subprograms, and that only those subprograms access the variables
directly. If given with the keyword “protected” and/or “accept”, it
enforces that global variables are accessed only by dedicated protected
subprograms or tasks, ensuring that no race condition is possible"
</Plug>

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: What is your opinion on Global Objects?

[Jeffrey Carter]

On 11/19/2014 02:13 AM, Hubert wrote:
> 
> Ok this is still an access of the global object directly from a subprogram. The
> subprogram then accesses the variable with the data ijnternally which is the
> same as accessing a global object. The data object itself is not passed through
> the parameters of the subprogram that uses it.

The package represents the object ("object" being a design concept). The
variables in the pkg body represent the state of the object, same as the private
fields of an object represented by an instance of a tagged type (or a "class"
type in some other languages). Note the use of State for the hidden variable in
Andersen's example, and the SPARK "state" annotations for such packages.

-- 
Jeff Carter
"How'd you like to hide the egg and gurgitate
a few saucers of mocha java?"
Never Give a Sucker an Even Break
101

Re: What is your opinion on Global Objects?

[Hubert]

Yes, I guess if something like that is called by a module or subprogram,
one has to make sure that this package is unit tested before the ones 
that use it are unit tested. I guess in the end there is no big 
difference whether you pass this sort of entity as a parameter or call 
it through these access functions. In the end, there are status 
variables maintained in a separate package, so I guess when you look at 
it this way, it doesn't really matter which way you chose, teh package 
must have been tested before it is used either way in other unit tests



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: What is your opinion on Global Objects?

[Stephen Leake]

Hubert <herrdoktor@fumanchu.com> writes:

> That basically is a vote for global objects. Whether they are accessed
> through a global variable or some sort of getter function that returns
> access, it means bypassing the parameters. Well from what I read here,
> there are no strong opinions for either concept. Strange, I wasn't
> able to find good arguments for or against the two concepts anywhere,

If you can really, truly, absolutely guarrantee that you will _never_
need two different copies of the data structure, then the singleton
pattern makes sense (data in a single variable in a package body).

If you ever need two different copies of the data structure, then you
need to pass it around in parameters.

The symbol table for a compiler is a good candidate for a singleton.

A database connection is not; you will need to copy the database from
one object to another when you change the schema or move to a new
backend in the future.

-- 
-- Stephe

Re: What is your opinion on Global Objects?

[sbelmont700]

For what it's worth, I'm in the "pass everything as an argument" camp (and really functional programming in general), and loathe the 'hidden state' setup, for the following reasons:
1. You are hardcoded to a particular implementation (i.e. no dispatching)
2. You always end up needing a second object, no matter much you think you don't think you will.
3. The majority of the program becomes impure
4. Things that access global objects are way more complex to try and test
5. Everything is compile-time constant (i.e. no creating or deleting things dynamically).

-sb

Re: What is your opinion on Global Objects?

[Adam Beneschan]

On Thursday, November 20, 2014 8:34:31 AM UTC-8, Stephen Leake wrote:
> 
> > That basically is a vote for global objects. Whether they are accessed
> > through a global variable or some sort of getter function that returns
> > access, it means bypassing the parameters. Well from what I read here,
> > there are no strong opinions for either concept. Strange, I wasn't
> > able to find good arguments for or against the two concepts anywhere,
> 
> If you can really, truly, absolutely guarrantee that you will _never_
> need two different copies of the data structure, then the singleton
> pattern makes sense (data in a single variable in a package body).
> 
> If you ever need two different copies of the data structure, then you
> need to pass it around in parameters.
> 
> The symbol table for a compiler is a good candidate for a singleton.

This doesn't seem right to me.  

I haven't followed the whole discussion closely, so I might have missed something...  But in the case of a symbol table, an Ada compiler that implements generics by "macro instantiation" is an example of why a symbol table should *not* be a singleton.  If the compiler rescans the text of the generic, the entire context (i.e. what symbols are visible) will change while the generic is being instantiated, and then it will change back at the end.  And of course the generic can instantiate another generic.

This doesn't mean that any data structures are being copied.  The "symbol table" could be implemented as a single access object, or as a smallish record that contains an access object that points to the root of the symbol table and has some other housekeeping info.  But it still wouldn't be a singleton.  Making it a singleton (or global) would mean that any time the context has to change, some subprogram has to save the global value into a local, change the global value, call whatever other subprogram will be using the new context, then restore the global value from the local.  I've worked with this kind of arrangement and have suffered from numerous migraines as a result.  (That's one of the reasons I try not to use singleton objects in general; there have been too many times when it's seemed clear that there needs to be only one instance of something, and it's come back to bite me.)

In any case, though, I don't know what it has to do with "copies of a data structure".  That seems to be the wrong criterion, especially in a case like a compiler symbol table.  Perhaps I just view the world too differently from you, or you're just used to working with different examples than I am.

                                -- Adam

Re: What is your opinion on Global Objects?

[J-P. Rosen]

Le 20/11/2014 21:33, sbelmont700@gmail.com a écrit :
> For what it's worth, I'm in the "pass everything as an argument" camp
> (and really functional programming in general), and loathe the
> 'hidden state' setup, for the following reasons:
Let's see what the other camp has to respond...

> 1. You are hardcoded to a particular implementation (i.e. no dispatching)
Yes, it is more static, therefore safer and more easily provable.
Dispatching is a very powerful tool, but only when you really need it.

> 2. You always end up needing a second object, no matter much you think you don't think you will.
Doesn't meet my experience. Knowing that by design there can be only one
object simplifies understanding and provability. You don't have to worry
about which object you are dealing with - there is only one.

> 3. The majority of the program becomes impure
??? Please explain you notion of "purity".

> 4. Things that access global objects are way more complex to try and test
Yes, when accessing in uncontrolled ways global variables from multiple
places. No with proper encapsulation (like here) with accessors and
selectors that can control exclusive access if necessary.

> 5. Everything is compile-time constant (i.e. no creating or deleting things dynamically).
I would regard this as a huge benefit - dynamicity has always been
opposed to simplicity and provability.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: What is your opinion on Global Objects?

[sbelmont700]

On Thursday, November 20, 2014 4:35:20 PM UTC-5, J-P. Rosen wrote:
>
> Let's see what the other camp has to respond...
> 

As you have pointed out, either way is a double-edged sword; one programmers rigid and inflexible code is another programmers safe and reliable code, and all engineering is compromise.  That being said, in my experiences, the only proven way to know when the customer is going to change the requirements is when he says they are never going to change the requirements.  For something like a game, assuming a fixed number (especially one) of anything is a surefire way to incur massive rework.  Suppose, for instance, the game evolves to a multiplayer version; a server might need to host a dynamic and always changing number of game engines.

>
> ??? Please explain you notion of "purity".
> 

I guess generally I mean "referentially transparent", but more practically I mean "pragma Pure".

-sb

Re: What is your opinion on Global Objects?

[Hubert]

> A database connection is not; you will need to copy the database from
> one object to another when you change the schema or move to a new
> backend in the future.
>
Yes my application is a little different from what most of you probably 
work on. Like I said, I am working on a multiplayer game and the things 
that are implemented as singletons here exist absolutely only once.

The reason for my question was not so much for my actual work but for 
future subprojects we will be doing where we want to attempt a different 
approach to the design, with more upfront planning and a scheme that is 
more like Structured Design, but with elements that allow for OOP 
elements, so we can't just take the old books by Yourdon et al and apply 
their technique, since we can't deny that there is value in small scale 
inheritance sometimes yet the techniques and diagrams for Structured 
Design don't take that into account since they are mostly from the 70s 
and 80s.

Anyway thanks a lot everybody for the input, I didn't think of global 
objects as subprogram calls with internal status variables before since 
I am kind of preoccupied with C++ thinking and look at most everything 
as a self sufficient object, so it's good to get a different perspective.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: What is your opinion on Global Objects?

[Hubert]

> As you have pointed out, either way is a double-edged sword; one programmers rigid and inflexible code is another programmers safe and reliable code, and all engineering is compromise.  That being said, in my experiences, the only proven way to know when the customer is going to change the requirements is when he says they are never going to change the requirements.  For something like a game, assuming a fixed number (especially one) of anything is a surefire way to incur massive rework.  Suppose, for instance, the game evolves to a multiplayer version; a server might need to host a dynamic and always changing number of game engines.



Our game is already a multiplayer game and although your a=point about 
customers changing their mind is generally true, in a scenario like ours 
it is not since we are customers, designers and programmers in one team, 
so there is no need to consider outside people or rather people with 
little understanding of how their ideas look when being realized in 
software and thus be likely to change their minds once they see the result.

Also, our software world does not so much consist of active objects or 
whatever is used in web or phone apps these days. Think of it more like 
an old fashioned mainframe system. Once it runs there will be changes 
for upgrades of course but nothing that requires a quick implementation 
or rapid reaction to changing demands, so the "inflexible" argument does 
not affect our case, although it may be important to consider in other 
scenarios.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: What is your opinion on Global Objects?

[Brad Moore]

On 2014-11-20 9:34 AM, Stephen Leake wrote:
> If you can really, truly, absolutely guarrantee that you will _never_
> need two different copies of the data structure, then the singleton
> pattern makes sense (data in a single variable in a package body).
>
> If you ever need two different copies of the data structure, then you
> need to pass it around in parameters.

Not entirely true. Another possibility is to use generic packages.
Each instantiation of the generic could contain an independent copy of 
the data structure. One can select which object to operate on by 
selecting and using the generic instantiation of interest.

I think that generally this is not a good design, but I have seen it 
used in a fair bit in practice. For this case, I generally prefer to see 
a type declared in the visible part of the package that can is passed as 
a parameter to the subprograms declared in the package.

This is generally more flexible. One can use the object as a component 
in a larger record structure, or protect access to certain objects, by 
wrapping them in a protected object.

Otherwise, if the singleton is buried in a package body without any 
protection around the object, if someone wants to use the instantiation 
from multiple tasks, the usage can be unsafe or error prone and messy,
and the object does not have composability.

However, there are probably certain abstractions where that approach 
makes sense.

For the singleton case, I tend to prefer the object inside the body of 
the package approach though.

Brad

Re: What is your opinion on Global Objects?

[Dmitry A. Kazakov]

On Thu, 20 Nov 2014 22:35:16 +0100, J-P. Rosen wrote:

> Le 20/11/2014 21:33, sbelmont700@gmail.com a écrit :
>> For what it's worth, I'm in the "pass everything as an argument" camp
>> (and really functional programming in general), and loathe the
>> 'hidden state' setup, for the following reasons:
> Let's see what the other camp has to respond...
> 
>> 1. You are hardcoded to a particular implementation (i.e. no dispatching)
> Yes, it is more static, therefore safer and more easily provable.

This is a bit contradictory. Proofs as such are always against some stated
things. That already presumes several instances. Some instances may
withstand the proof some don't. Thus the idea of proving an inherent
singleton looks somewhat dubious. Singleton is only in the usage not a
property.

Anyway proving things about a type (singleton-object) might be easier than
doing this for an ad-hoc package.

> Dispatching is a very powerful tool, but only when you really need it.

Dispatching does not make sense for singletons, but Ada won't do any
dispatch anyway since the object's type is not class-wide.

>> 2. You always end up needing a second object, no matter much you think you
>> don't think you will.
> Doesn't meet my experience. Knowing that by design there can be only one
> object simplifies understanding and provability. You don't have to worry
> about which object you are dealing with - there is only one.

But the design may change and maintaining changes on the client side is
easier when the object is properly typed rather than when it is implicit,
in an assorted sets of subprograms stuffed into a package.

And you forgot about reuse. A singleton implementation may use some other
types implementations or provide its implementation for reuse.

>> 3. The majority of the program becomes impure
> ??? Please explain you notion of "purity".

I understood it as:

Pure = the only side effect is on the mutable arguments and/or the result.

>> 5. Everything is compile-time constant (i.e. no creating or deleting things dynamically).
> I would regard this as a huge benefit - dynamicity has always been
> opposed to simplicity and provability.

Huh, that reminds me of a relatively fresh discussion about termination of
a library-level task in Ada. A typical singleton, isn't it? Yet impossible
to terminate on application exit! Making it an access type (=not a
singleton) or moving out of the library level solved the problem.

Ego, it is not simple to have things static, though most things aren't any
static anyway, not even keeping them at the library level is simple.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is your opinion on Global Objects?

[Stephen Leake]

Adam Beneschan <adambeneschan@gmail.com> writes:

> On Thursday, November 20, 2014 8:34:31 AM UTC-8, Stephen Leake wrote:
>> 
>> > That basically is a vote for global objects. Whether they are accessed
>> > through a global variable or some sort of getter function that returns
>> > access, it means bypassing the parameters. Well from what I read here,
>> > there are no strong opinions for either concept. Strange, I wasn't
>> > able to find good arguments for or against the two concepts anywhere,
>> 
>> If you can really, truly, absolutely guarrantee that you will _never_
>> need two different copies of the data structure, then the singleton
>> pattern makes sense (data in a single variable in a package body).
>> 
>> If you ever need two different copies of the data structure, then you
>> need to pass it around in parameters.
>> 
>> The symbol table for a compiler is a good candidate for a singleton.
>
> This doesn't seem right to me.  
>
> I haven't followed the whole discussion closely, so I might have
> missed something... But in the case of a symbol table, an Ada compiler
> that implements generics by "macro instantiation" is an example of why
> a symbol table should *not* be a singleton. If the compiler rescans
> the text of the generic, the entire context (i.e. what symbols are
> visible) 

That's not the _entire_ symbol table, just one subtree.

I've never implemented a compiler, but I have implemented an
interpreter; it has a singleton symbol table.

I imagine "context" is a pointer into the symbol table, showing what is
visible at the current code position.

It certainly depends on how the compiler uses the symbol table.

-- 
-- Stephe

Re: What is your opinion on Global Objects?

[Randy Brukardt]

"Adam Beneschan" <adambeneschan@gmail.com> wrote in message 
news:65f2470c-0828-4f97-9f0e-f11966896c06@googlegroups.com...
...
>> The symbol table for a compiler is a good candidate for a singleton.
>
>This doesn't seem right to me.

It does to me. :-)

>I haven't followed the whole discussion closely, so I might have missed 
>something...  But
>in the case of a symbol table, an Ada compiler that implements generics by 
>"macro
>instantiation" is an example of why a symbol table should *not* be a 
>singleton.  If the
>compiler rescans the text of the generic, the entire context (i.e. what 
>symbols are visible)
>will change while the generic is being instantiated, and then it will 
>change back at the end.
>And of course the generic can instantiate another generic.

This makes no sense whatsoever. First of all, you can't instantiate a 
generic by rescanning the text, because all of the objects are bound when 
they are initially compiled. Most likely, everything would resolve wrong. 
Trying to make that work would be an absolute nightmare.

Our symboltable is purely a singleton; it reflects exactly the declarations 
available to the program at the current point in the compilation. (Our 
compiler is syntax-driven, so for most purposes it can be considered one 
pass -- we never go backwards in the source or symbols). Every change in the 
code changes the symboltable. (Initially, we deleted declarations as they 
went out of scope, but that always seemed to leave dangling pointers and was 
just a lot more complex than marking things as invisble.) That's why 
implementing ASIS is impractical in our compiler -- we don't ever have a 
view of the compilation as a whole to work from.

Generic instantiations are implemented by copying the symboltable for the 
generic unit and making the changes required by the instantiation. We don't 
do macro expansion, but if we did, we'd do it by duplicating a tree form of 
the unit (in which all of the symbols are already bound). Trying to work 
from the text is madness (especially as our parser is also a singleton)!

Now, I'm well aware that anything done in someone else's compiler is totally 
weird -- the things that other ARG members consider hard (or easy for that 
matter) often make little sense to me. I could imagine structuring a symbol 
table as a set of units (which would not be a singleton). [I can't imagine 
the Rational compiler, which supposely doesn't have a symbol table at all. 
But whatever.]

Anyway, I think the main point is that there really is no rules. Sometimes a 
singleton package is the best design. Sometimes a bunch of global spagetti 
is about all that would ever work (that's probably the best description of 
the symbol table in Janus/Ada)! [We couldn't afford the code that 
encapsulation would have cost back on CP/M and MS-DOS -- indeed, we use 
jumps, not calls for elaboration because we saved the call setup code *200 
units -- which was enough to make a big difference when getting code to fit 
into 64K RAM.]

                                           Randy.

Re: What is your opinion on Global Objects?

[J-P. Rosen]

Le 21/11/2014 10:01, Dmitry A. Kazakov a écrit :
> On Thu, 20 Nov 2014 22:35:16 +0100, J-P. Rosen wrote:
> 
>>> 1. You are hardcoded to a particular implementation (i.e. no dispatching)
>> Yes, it is more static, therefore safer and more easily provable.
> 
> This is a bit contradictory. Proofs as such are always against some stated
> things. That already presumes several instances. Some instances may
> withstand the proof some don't. Thus the idea of proving an inherent
> singleton looks somewhat dubious. Singleton is only in the usage not a
> property.
Not at all. Where we differ is that you are thinking in terms of classes
first, then instances. You see the properties at class level, and then a
singleton (a class with a single instance) makes little sense.

I am thinking in terms of objects first. Objects have properties. If
several objects share a common behaviour, then I group them into
"equivalence classes", and the common properties of the objects become
the properties of the class. If you think objects first, singletons make
perfect sense.

> And you forgot about reuse. A singleton implementation may use some other
> types implementations or provide its implementation for reuse.
You implicitely think of reuse by inheritance. I favor reuse by composition.

> 
>>> 3. The majority of the program becomes impure
Not really. If your problem requires a global state, then it is
"impure". Whether you use global variables in a package or a global
object gathering the data that you pass to subprograms does not change
anything.

>>> 5. Everything is compile-time constant (i.e. no creating or deleting things dynamically).
>> I would regard this as a huge benefit - dynamicity has always been
>> opposed to simplicity and provability.
> 
> Huh, that reminds me of a relatively fresh discussion about termination of
> a library-level task in Ada. A typical singleton, isn't it? Yet impossible
> to terminate on application exit! 
??? Select ... or terminate works perfectly well for library tasks. I do
that all the time.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: What is your opinion on Global Objects?

[Dmitry A. Kazakov]

On Sat, 22 Nov 2014 08:46:36 +0100, J-P. Rosen wrote:

> Le 21/11/2014 10:01, Dmitry A. Kazakov a écrit :
>> On Thu, 20 Nov 2014 22:35:16 +0100, J-P. Rosen wrote:
>> 
>>>> 1. You are hardcoded to a particular implementation (i.e. no dispatching)
>>> Yes, it is more static, therefore safer and more easily provable.
>> 
>> This is a bit contradictory. Proofs as such are always against some stated
>> things. That already presumes several instances. Some instances may
>> withstand the proof some don't. Thus the idea of proving an inherent
>> singleton looks somewhat dubious. Singleton is only in the usage not a
>> property.
> Not at all. Where we differ is that you are thinking in terms of classes
> first, then instances. You see the properties at class level, and then a
> singleton (a class with a single instance) makes little sense.

Correction: not classes, types. An instance, an object has a type.
Instances of types form a class.

Classes are relevant only when reuse comes in question.

> I am thinking in terms of objects first. Objects have properties. If
> several objects share a common behaviour, then I group them into
> "equivalence classes", and the common properties of the objects become
> the properties of the class. If you think objects first, singletons make
> perfect sense.

Yes. That is what OOA/D say. I don't believe in OOA/D in software design.
To me it is ad hocery and, worse, untyped.

>> And you forgot about reuse. A singleton implementation may use some other
>> types implementations or provide its implementation for reuse.
> You implicitely think of reuse by inheritance. I favor reuse by composition.

So what? You could find useful to reuse parts of the singleton
implementation per composition as well.

>>>> 3. The majority of the program becomes impure
> Not really. If your problem requires a global state, then it is
> "impure". Whether you use global variables in a package or a global
> object gathering the data that you pass to subprograms does not change
> anything.

It does for the clients because it clearly defines the context the client
is allowed to update. The origin of the context if it is global or not,
plays no role to the client. In particular, the functionality of the client
does not depend on whether the context is a singleton. One constraint less
to be aware of, safer is the design.

>>>> 5. Everything is compile-time constant (i.e. no creating or deleting things dynamically).
>>> I would regard this as a huge benefit - dynamicity has always been
>>> opposed to simplicity and provability.
>> 
>> Huh, that reminds me of a relatively fresh discussion about termination of
>> a library-level task in Ada. A typical singleton, isn't it? Yet impossible
>> to terminate on application exit! 
> ??? Select ... or terminate works perfectly well for library tasks. I do
> that all the time.

It was not possible to have terminate alternative (in practice it is almost
always so).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de