Once creation procedures
Miguel Oliveira e Silva
OOSC2ed clearly states (section 8.4: Creation Procedures, pg: 236-239),
that the use of explicit creation procedures is only the fourth
step on a new instance creation (first a new object is created,
then the object attributes are initialized to the default values,
and before the [possible] creation procedure invocation the instance
reference is attached to the appropriate entity). This means that
once creation procedures are a way, not to implement singletons,
but to provide explicit initializations for the first instance
created, and the default values to the remaining (which BTW,
may pose correctness problems if the default values don't
obey the class invariant).
But is this the more appropriate and useful behavior?
Instead, why not get something useful out of once creation
procedures, making them an appropriate [is it?] way for ensuring
single instance classes?
Currently, to make singletons with Eiffel we must rely on external
once functions (which may be bypassed, although an appropriate
export restriction may minimize the problem).
Due to the fact that Eiffel does not have once type modifiers,
this behavior might be a simple and clear alternative.
Any thoughts?
-miguel
--
Miguel Oliveira e Silva email: m...@det.ua.pt
Dep. de Electrónica e Telecomunicações / IEETA
Universidade de Aveiro - PORTUGAL
phone: +351 234 370375 fax: +351 234 370545
www: http://www.ieeta.pt/~mos
Berend de Boer
> Currently, to make singletons with Eiffel we must rely on external
> once functions (which may be bypassed, although an appropriate
> export restriction may minimize the problem).
I didn't get this part. Singletons in Eiffel are usually written with
an invariant:
class
SINGLETON
feature {NONE} -- private
the_singleton: SINGLETON is
deferred
end
invariant
remain_single: Current = the_singleton
end
What's wrong with that?
--
Groetjes,
Berend. (-:
Berend de Boer
> Currently, to make singletons with Eiffel we must rely on external
> once functions (which may be bypassed, although an appropriate
> export restriction may minimize the problem).
I didn't get this part. Singletons in Eiffel are usually written with
Doug Pardee
> procedures, making them an appropriate [is it?] way for ensuring
> single instance classes?
The problem here is that the goal of single-instance classes
(Singletons) is inappropriate. Singleton is a kludge which arose from
a language (C++) which celebrates kludges.
Here are some of the issues:
1. A single instance in what context? All the universe? Within a
subnet? Within a multi-system cluster? Within a single computing node?
Within an application? Within a process? Within a thread?
In the old days, when there was exactly one process and one thread
running in one application, and only one application running on a
single-CPU machine which existed in isolation, the answer was more
obvious. Today, we have so many different contexts to deal with. The
"once" mechanism provides no choice of context.
2. It is not the class designer's responsibility to determine whether
or not his class should have only one instance within a context. The
class provides a set of services; it is up to the client to determine
how many instances of the class are appropriate for that client's
needs. This is why, in Eiffel, we must have a separate class which
implements the "Singleton-ness".
3. It follows from the Open-Closed Principle that any restrictions on
the number of instances which are imposed by a client class can always
be overridden by a descendant of that client class.
Many times the Singleton pattern is used simply to create global
variables. Global variables are widely held to be a Bad Thing because
of the uncontrolled coupling that almost inevitably results. Calling a
Global Variable a Singleton does not make it any less troublesome.
Legitimate Singletons are more properly served by having them
described as attributes within an appropriate "context" class.
-- Doug Pardee dougp...@yahoo.com
Miguel Oliveira e Silva
I see two problems with this solution.
The first one is the different degree of reliability between run-time
verification (using assertions), and compile time assurance (with
a mechanism for single instance classes).
The second is simplicity. The class SINGLETON is not the only
thing needed, all of its clients will have to ensure that there will
be only one creation instruction, and the reference for this [unique]
instance will have to be passed to where its needed (the easiest
solution here is to use an external once function...).
--
I did not yet receive Doug Pardee's message in my news server
[I've seen it in dejanews], but - although I agree with the context
related dependency of singletons - I would like to point out that
the onceness of a routine is not inherited to possible redefinitions
which allows eventual adaptions to new contexts [in line with
the Open Close Principle].
> --
> Groetjes,
>
> Berend. (-:
Miguel Oliveira e Silva
> > Instead, why not get something useful out of once creation
> > procedures, making them an appropriate [is it?] way for ensuring
> > single instance classes?
Doug Pardee wrote:
> The problem here is that the goal of single-instance classes
> (Singletons) is inappropriate. Singleton is a kludge which arose from
> a language (C++) which celebrates kludges.
>
> Here are some of the issues:
>
> 1. A single instance in what context? All the universe? Within a
> subnet? Within a multi-system cluster? Within a single computing node?
> Within an application? Within a process? Within a thread?
That's the class designer problem. There are situations where a program
singleton (or even a thread scope one) is useful and needed (for example,
when dealing with unique shared resources - in general - to describe
unique program [thread] abstractions).
You are saying [and I agree] that program [thread] singletons are not the
solution for singletons with other scopes. But is that a reason to remove
that [safer, and simpler] mechanism from where its needed?
What do we gain with that?
As I said in a previous message the onceness of a routine is not inherited
by descendant classes, which means that classes with once creation procedures,
can be redefined for a different instantiation semantics.
> In the old days, when there was exactly one process and one thread
> running in one application, and only one application running on a
> single-CPU machine which existed in isolation, the answer was more
> obvious. Today, we have so many different contexts to deal with. The
> "once" mechanism provides no choice of context.
That's true. Maybe the idea for a explicit scope for once routines is
something to explore and think about. But it seems to me that once
(whatever the scope) creation procedures are even more useful if
there was (or will be) such a mechanism. Isn't it?
> 2. It is not the class designer's responsibility to determine whether
> or not his class should have only one instance within a context.
Why not?
> The
> class provides a set of services; it is up to the client to determine
> how many instances of the class are appropriate for that client's
> needs. This is why, in Eiffel, we must have a separate class which
> implements the "Singleton-ness".
It's the class designer responsibility to implement whatever abstraction
it needs to solve his (her) problem. It singletons are the right tool for
the work, and the correct abstraction, why not use it?
> 3. It follows from the Open-Closed Principle that any restrictions on
> the number of instances which are imposed by a client class can always
> be overridden by a descendant of that client class.
That behavior can be redefined not on client's descendants but on the
original [supplier] singleton class (if the class ADT is almost, but not
exactly what we need we adapt it using inheritance [as always]).
> Many times the Singleton pattern is used simply to create global
> variables. Global variables are widely held to be a Bad Thing because
> of the uncontrolled coupling that almost inevitably results. Calling a
> Global Variable a Singleton does not make it any less troublesome.
You have a point here. I'm not defending the use of singletons to replace
["considered harmful"] global variables, but to global shared abstractions.
> Legitimate Singletons are more properly served by having them
> described as attributes within an appropriate "context" class.
Inherited by all the classes in that context?
> -- Doug Pardee dougp...@yahoo.com
Patrick Doyle
Miguel Oliveira e Silva <m...@det.ua.pt> wrote:
>Berend de Boer wrote:
>
>> invariant
>> remain_single: Current =3D the_singleton
>>
[...]
>>
>> What's wrong with that?
>
>I see two problems with this solution.
>
>The first one is the different degree of reliability between run-time
>verification (using assertions), and compile time assurance (with
>a mechanism for single instance classes).
Woah there. Of course you are aware that assertions aren't
about run-time verification. They are about Design by Contract.
After all, this is an Eiffel newsgroup!
To me, Berend's solution is perfectly adequate, and those who
can't use it properly probably shouldn't be using Eiffel anyway. :-)
--
--
Patrick Doyle
doy...@eecg.toronto.edu
Miguel Oliveira e Silva
> In article <3B9F3498...@det.ua.pt>,
> Miguel Oliveira e Silva <m...@det.ua.pt> wrote:
> >Berend de Boer wrote:
> >
> >> invariant
> >> remain_single: Current =3D the_singleton
> >>
> [...]
> >>
> >> What's wrong with that?
> >
> >I see two problems with this solution.
> >
> >The first one is the different degree of reliability between run-time
> >verification (using assertions), and compile time assurance (with
> >a mechanism for single instance classes).
>
> Woah there. Of course you are aware that assertions aren't
> about run-time verification.
I am aware that assertions are not *just* for run-time checking
(as I am that - in general [there are same interesting exceptions
in sequential programming if we have a smart compiler] - that's
the only time for verifying them), but that was not my point.
Neither was an attempt to reduce the importance of Design by
Contract to run-time checking (that would be absurd).
My point, Patrick, is that there is a substantial reliability
difference between caching [eventual] errors at compile time,
than at run time (surely you agree with that).
(The same argument holds for Eiffel's static [strongest] typing
versus Smalltalk's dynamic [weakest] typing.)
> They are about Design by Contract.
> After all, this is an Eiffel newsgroup!
>
> To me, Berend's solution is perfectly adequate, and those who
> can't use it properly probably shouldn't be using Eiffel anyway. :-)
Well in fact with the actual Eiffel standard (ETL), Berend's proposal
is one of the best possible solutions (no argue there). But the mentioned
new semantics for once creation procedures might provide a better one,
which is what I'm trying to argument about.
>
> --
-miguel
Patrick Doyle
Yes, that's true. There are situations like this already, where
contracts would be sufficient in principle, but Eiffel provides
stronger guarantees anyway. For example, Eiffel syntactically forces
creations procedures to be called when objects are created.