Re: What is your opinion on Global Objects?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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