Ada-Singleton-Why does it work like this?

Ada-Singleton-Why does it work like this?

[patrick.gunia]

Hi all,
I´m currently working on implementing several design patterns in Ada,
and I found some code concerning the Singleton-pattern when searching
through the posts of this group. I used this code and it all worked as
expected. My problem is, that I don´t ave any idea, why it does...here
is my code:

package Singleton is

	type Singleton_Type (<>) is tagged limited private;
	type Singleton_Access is access all Singleton_Type;

	function return_Single return Singleton_Access;

	procedure setValues(input : in out Singleton_Access; valueIN :
Integer; valueIN2 : Integer);
	procedure print_something(input : Singleton_Access);


	private
	type Singleton_Type is tagged limited record
		value : Integer;
		value2 : Integer;
	end record;

end Singleton;

Here is the implementation part:

package body Singleton is
	It: aliased Singleton_Type;
	procedure setValues(input : in out Singleton_Access; valueIN :
Integer; valueIN2 : Integer) is
		begin
			input.value := valueIN;
			input.value2 := valueIN2;

		end setValues;

	function return_Single return Singleton_Access is
		begin
			return It'Access;
		end return_Single;

	procedure print_something(input : Singleton_Access) is
		begin
			put(input.value);
			put(input.value2);
		end print_something;

end Singleton;

As far as I get it, is the declaration "type Singleton_Type (<>) is
tagged limited private;" the key-feature to realize the Singleton
pattern, but how, and why does this work? I looked through my Ada-
book, searched the web but didn´t find an explanation for this
construct! Could you please tell me, what exactly happens when I use
(<>) within a type-declaration and why it is necessary for the
Singleton-Implementation?

Thanks a lot!
Patrick

Re: Ada-Singleton-Why does it work like this?

[Pascal Obry]

Patrick,

> package Singleton is
> 
> 	type Singleton_Type (<>) is tagged limited private;

This declares an unconstrained type. It means that an initialization is
needed when declaring object of type Singleton_Type. This is a bit like
the String type, you cannot say:

   S : String;

But, this is valid:

   S : String := "toto";

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada-Singleton-Why does it work like this?

[Jeffrey R. Carter]

patrick.gunia@googlemail.com wrote:
> Hi all,
> I�m currently working on implementing several design patterns in Ada,
> and I found some code concerning the Singleton-pattern when searching
> through the posts of this group. I used this code and it all worked as
> expected. My problem is, that I don�t ave any idea, why it does...here
> is my code:
> 
> package Singleton is
> 
> 	type Singleton_Type (<>) is tagged limited private;
> 	type Singleton_Access is access all Singleton_Type;
> 
> 	function return_Single return Singleton_Access;
> 
> 	procedure setValues(input : in out Singleton_Access; valueIN :
> Integer; valueIN2 : Integer);
> 	procedure print_something(input : Singleton_Access);
> 
> 
> 	private
> 	type Singleton_Type is tagged limited record
> 		value : Integer;
> 		value2 : Integer;
> 	end record;
> 
> end Singleton;

This is a very poor solution to the problem. A much simpler solution is

package Singleton is
    procedure Set (Value_1 : in Integer; Value_2 : in Integer);

    procedure Print;
end Singleton;

-- 
Jeff Carter
"We use a large, vibrating egg."
Annie Hall
44

Re: Ada-Singleton-Why does it work like this?

[Ludovic Brenta]

Patrick Gunia wrote:
> Hi all,
> I´m currently working on implementing several design patterns in Ada,
> and I found some code concerning the Singleton-pattern when searching
> through the posts of this group. I used this code and it all worked as
> expected. My problem is, that I don´t ave any idea, why it does...here
> is my code:
>
> package Singleton is
>
>         type Singleton_Type (<>) is tagged limited private;
>         type Singleton_Access is access all Singleton_Type;
>
>         function return_Single return Singleton_Access;
>
>         procedure setValues(input : in out Singleton_Access; valueIN :
> Integer; valueIN2 : Integer);
>         procedure print_something(input : Singleton_Access);
>
>         private
>         type Singleton_Type is tagged limited record
>                 value : Integer;
>                 value2 : Integer;
>         end record;
>
> end Singleton;
>
> Here is the implementation part:
>
> package body Singleton is
>         It: aliased Singleton_Type;
>         procedure setValues(input : in out Singleton_Access; valueIN :
> Integer; valueIN2 : Integer) is
>                 begin
>                         input.value := valueIN;
>                         input.value2 := valueIN2;
>
>                 end setValues;
>
>         function return_Single return Singleton_Access is
>                 begin
>                         return It'Access;
>                 end return_Single;
>
>         procedure print_something(input : Singleton_Access) is
>                 begin
>                         put(input.value);
>                         put(input.value2);
>                 end print_something;
>
> end Singleton;
>
> As far as I get it, is the declaration "type Singleton_Type (<>) is
> tagged limited private;" the key-feature to realize the Singleton
> pattern, but how, and why does this work? I looked through my Ada-
> book, searched the web but didn´t find an explanation for this
> construct! Could you please tell me, what exactly happens when I use
> (<>) within a type-declaration and why it is necessary for the
> Singleton-Implementation?

As Pascal replied, the (<>) declares that Singleton_Type is
unconstrained; because, in addition, it is private, it is therefore
impossible to declare objects of this type outside the package
Singleton.  Consider:

with Singleton;
procedure Wrong is
   Second_Singleton : Singleton.Singleton_Type;
   -- error, the type is unconstrained

But your example is much too complicated.  Why is Singleton_Type
tagged?  Why pass parameters to all subprograms when there is only one
object anyway?  A proper singleton looks like this:

package Singleton is
   procedure Set (Value_1, Value_2 : in Integer);
   procedure Print;
private
   Value_1, Value_2 : Integer;
end Singleton;

package body Singleton is
   procedure Set (Value_1, Value_2 : in Integer) is
   begin
      Singleton.Value_1 := Value_1;
      Singleton.Value_2 := Value_2;
   end Set;

   procedure Print is
   begin
      Put (Value_1);
      Put (Value_2);
   end Print;
end Singleton;

A variation of this design pattern is when you want to allocate the
singleton dynamically on first use and never deallocate it.  In this
situation, you do need an access type and value but you do not need to
expose them to clients; in fact the whole allocation business should
be confined to the body of the package:

package body Singleton is

   type Singleton_Type is record
      Value_1, Value_2 : Integer;
   end record;
   type Singleton_Access is access Singleton_Type;
   The_Singleton : Singleton_Access;

   procedure Allocate_If_Null is
   begin
      if The_Singleton = null then
         The_Singleton := new Singleton_Type;
      end if;
   end Allocate_If_Null;

   procedure Set (Value_1, Value_2 : in Integer) is
   begin
      Allocate_If_Null;
      The_Singleton.Value_1 := Value_1;
      The_Singleton.Value_2 := Value_2;
   end Set;

   procedure Print is
      -- raises Constraint_Error if The_Singleton = null, i.e. if Set
never called
   begin
      Put (The_Singleton.Value_1);
      Put (The_Singleton.Value_2);
   end Print;

end Singleton;

HTH

--
Ludovic Brenta.

Re: Ada-Singleton-Why does it work like this?

[Dmitry A. Kazakov]

On Tue, 24 Mar 2009 12:01:00 -0700 (PDT), patrick.gunia@googlemail.com
wrote:

> I�m currently working on implementing several design patterns in Ada,
> and I found some code concerning the Singleton-pattern when searching
> through the posts of this group.

A side note. Singleton is not needed in Ada. Arguably the only valid use of
singleton is execution of some piece of code once upon elaboration of some
module. In Ada this is achieved by putting elaboration code put in the body
of corresponding package:

package body Foo is
   ... -- Implementation of the entities declared in Foo

begin
   ... -- Elaboration code, executed once
end Foo;

A related, though a bit suspicious use of singleton is when it encapsulates
a managed global state is achieved again by a package. See the post of
Jeffrey Carter that illustrates this case.

The bottom lime. Singleton pattern is used only in the languages which bind
visibility to type. In Ada visibility is bound directly to the module
(package), which eliminates any need in this pattern.

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

Re: Ada-Singleton-Why does it work like this?

[Martin]

On Mar 24, 8:47 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> patrick.gu...@googlemail.com wrote:
> > Hi all,
> > I´m currently working on implementing several design patterns in Ada,
> > and I found some code concerning the Singleton-pattern when searching
> > through the posts of this group. I used this code and it all worked as
> > expected. My problem is, that I don´t ave any idea, why it does...here
> > is my code:
>
> > package Singleton is
>
> >    type Singleton_Type (<>) is tagged limited private;
> >    type Singleton_Access is access all Singleton_Type;
>
> >    function return_Single return Singleton_Access;
>
> >    procedure setValues(input : in out Singleton_Access; valueIN :
> > Integer; valueIN2 : Integer);
> >    procedure print_something(input : Singleton_Access);
>
> >    private
> >    type Singleton_Type is tagged limited record
> >            value : Integer;
> >            value2 : Integer;
> >    end record;
>
> > end Singleton;
>
> This is a very poor solution to the problem. A much simpler solution is
>
> package Singleton is
>     procedure Set (Value_1 : in Integer; Value_2 : in Integer);
>
>     procedure Print;
> end Singleton;

But you can not derive a class from this:

with Singletons; use Singletons;
package Print_Managers is
   type Print_Manager is new Singleton with private;
   -- There should only be 1 print manager
private
   -- implementation
end Print_Managers;

Now you could argue that there should just be a "package
Print_Manager" and no need for a Print_Manager type...

...and the idea that you can derive from a 'Singleton' type rather
defeats it as a 'pattern' but that's no bad thing IMHO! :-)

Cheers
-- Martin

Re: Ada-Singleton-Why does it work like this?

[Jeffrey R. Carter]

Martin wrote:
> 
> But you can not derive a class from this:

Since I am not a fan of programming by extension, I consider this a good thing.

> Now you could argue that there should just be a "package
> Print_Manager" and no need for a Print_Manager type...

Precisely. If you need several of these, then the package should be generic. Can 
you call it a singleton when you have several instances?

-- 
Jeff Carter
"We use a large, vibrating egg."
Annie Hall
44

Re: Ada-Singleton-Why does it work like this?

[Dmitry A. Kazakov]

On Tue, 24 Mar 2009 17:10:11 -0700 (PDT), Martin wrote:

> On Mar 24, 8:47�pm, "Jeffrey R. Carter"

>> This is a very poor solution to the problem. A much simpler solution is
>>
>> package Singleton is
>> � � procedure Set (Value_1 : in Integer; Value_2 : in Integer);
>>
>> � � procedure Print;
>> end Singleton;
> 
> But you can not derive a class from this:

Firstly you can. There are child packages in Ada, they are equivalent to
derivation.

Secondly, you may not because it is a singleton. A derived variant would be
meaningless without making an instance of, which would be *another*
instance of now non-singleton.

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

Re: Ada-Singleton-Why does it work like this?

[patrick.gunia]

> As Pascal replied, the (<>) declares that Singleton_Type is
> unconstrained; because, in addition, it is private, it is therefore
> impossible to declare objects of this type outside the package
> Singleton.  Consider:
>
> with Singleton;
> procedure Wrong is
>    Second_Singleton : Singleton.Singleton_Type;
>    -- error, the type is unconstrained
>
> But your example is much too complicated.  Why is Singleton_Type
> tagged?  Why pass parameters to all subprograms when there is only one
> object anyway?  A proper singleton looks like this:
I used a tagged type because I wanted to use the Singleton
implementation as bsae class for other classes with more functionality
though sharing the singleton behaviour. Your right concerning the
parameter passing, if there´s only one instance, the parameter isn´t
necessary. Still I don´t get how the unconstrained type limits the
number of instances to 1. As Pascal said, this can be compared to the
String class which is implemenented as an unconstrained array of
Characters. Thus Strings either have to be initialized with a phrase
or you have to limit the range. Though I´m still able to create
hundreds of Strings in my program. Which mechanism is responsible for
prohibiting this to my singleton class? I mean, if I compare this type
to a String-variable, I could also say instance : Singleton_Type
(1..120); (something like this...) => But the compiler complains, but
why does he?


>
> package Singleton is
>    procedure Set (Value_1, Value_2 : in Integer);
>    procedure Print;
> private
>    Value_1, Value_2 : Integer;
> end Singleton;
>
> package body Singleton is
>    procedure Set (Value_1, Value_2 : in Integer) is
>    begin
>       Singleton.Value_1 := Value_1;
>       Singleton.Value_2 := Value_2;
>    end Set;
>
>    procedure Print is
>    begin
>       Put (Value_1);
>       Put (Value_2);
>    end Print;
> end Singleton;
>
> A variation of this design pattern is when you want to allocate the
> singleton dynamically on first use and never deallocate it.  In this
> situation, you do need an access type and value but you do not need to
> expose them to clients; in fact the whole allocation business should
> be confined to the body of the package:
>
> package body Singleton is
>
>    type Singleton_Type is record
>       Value_1, Value_2 : Integer;
>    end record;
>    type Singleton_Access is access Singleton_Type;
>    The_Singleton : Singleton_Access;
>
>    procedure Allocate_If_Null is
>    begin
>       if The_Singleton = null then
>          The_Singleton := new Singleton_Type;
>       end if;
>    end Allocate_If_Null;
>
>    procedure Set (Value_1, Value_2 : in Integer) is
>    begin
>       Allocate_If_Null;
>       The_Singleton.Value_1 := Value_1;
>       The_Singleton.Value_2 := Value_2;
>    end Set;
>
>    procedure Print is
>       -- raises Constraint_Error if The_Singleton = null, i.e. if Set
> never called
>    begin
>       Put (The_Singleton.Value_1);
>       Put (The_Singleton.Value_2);
>    end Print;
>
> end Singleton;
>
> HTH
>
> --
> Ludovic Brenta.

Re: Ada-Singleton-Why does it work like this?

[patrick.gunia]

On 24 Mrz., 22:21, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 24 Mar 2009 12:01:00 -0700 (PDT), patrick.gu...@googlemail.com
> wrote:
>
> > I´m currently working on implementing several design patterns in Ada,
> > and I found some code concerning the Singleton-pattern when searching
> > through the posts of this group.
>
> A side note. Singleton is not needed in Ada. Arguably the only valid use of
> singleton is execution of some piece of code once upon elaboration of some
> module. In Ada this is achieved by putting elaboration code put in the body
> of corresponding package:
>
> package body Foo is
>    ... -- Implementation of the entities declared in Foo
>
> begin
>    ... -- Elaboration code, executed once
> end Foo;
>
> A related, though a bit suspicious use of singleton is when it encapsulates
> a managed global state is achieved again by a package. See the post of
> Jeffrey Carter that illustrates this case.
>
> The bottom lime. Singleton pattern is used only in the languages which bind
> visibility to type. In Ada visibility is bound directly to the module
> (package), which eliminates any need in this pattern.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Maybe I´m getting something wrong, but from my point of view,
Singleton offers more possibilities than just the execution of some
code on elaboration of some module.I like the dynamic version Ludovic
described. It also offers the possibility to change the number of
instances later on and thus increases the adaptability. When you say
that Singleton isn´t necessary in Ada this might come from the fact
that it can´t be implemented as in other languages, though using such
a construct might increase readability of the code.

Re: Ada-Singleton-Why does it work like this?

[Jean-Pierre Rosen]

patrick.gunia@googlemail.com a �crit :
> [..] Which mechanism is responsible for
> prohibiting this to my singleton class?
Very simple: variables of this type have to be initialized. However, the
type is private (you cannot provide a value in the form of an aggregate
f.e.), and there is no function that returns a value of the type.

=> There is no way to have a value of the type
=> There is no possible initialization value
=> You cannot declare a variable of the type
QED

Of course, in the package /body/ you see the full declaration, that's
why you are allowed to declare a variable there.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada-Singleton-Why does it work like this?

[patrick.gunia]

Yet another question, if my Singleton_Type is unconstrained, why does
Ada allow creating Access-Types to unconstrained types allowing to
access there record-properties, while not allowing to create an
instance of Singleton_Type directly? I thought that Ada demands a
declaration of an instance before creating an Access-Type to access
it? Maybe I´m mixing in C++, but if I declare a pointer in C++ I
either have to create a new instance using "new" in heap-memory where
the pointer points to or I have to use references and then let the
pointer point to a reference. In both cases I first have to create an
object and then let the pointer point to it. When I use access types
in Ada in my example it´s possible to create a pointer to a class
which can´t be instantiated, because it is unconstrained. Though it
works to access the record-properties using the access-type. Could
anyone tell me what I´m getting wrong concerning Ada?

Thank you!

Re: Ada-Singleton-Why does it work like this?

[Dmitry A. Kazakov]

On Wed, 25 Mar 2009 03:07:18 -0700 (PDT), patrick.gunia@googlemail.com
wrote:

> Maybe I�m getting something wrong, but from my point of view,
> Singleton offers more possibilities than just the execution of some
> code on elaboration of some module.I like the dynamic version Ludovic
> described. It also offers the possibility to change the number of
> instances later on and thus increases the adaptability.

Sorry, but a singleton with more than one instance is not a singleton.

> When you say
> that Singleton isn�t necessary in Ada this might come from the fact
> that it can�t be implemented as in other languages, though using such
> a construct might increase readability of the code.

No, it is rather so, that the problems solved in other languages using the
singleton pattern, in Ada are solved using different patterns.

There is a general note about software design patterns, that they usually
indicate some language deficiency. If a language has a construct to express
the idea behind the pattern, then it is not a pattern anymore. Pattern
assumes some manual, yet routine work on the programmer side, which cannot
be taken over by the language, because ...

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

Re: Ada-Singleton-Why does it work like this?

[Jean-Pierre Rosen]

patrick.gunia@googlemail.com a �crit :
> [...] When you say
> that Singleton isn�t necessary in Ada this might come from the fact
> that it can�t be implemented as in other languages, though using such
> a construct might increase readability of the code.

I think there is a contradiction between "class" and "singleton". The
term "class" is used, because it includes a set of objects that are
equivalent for some point of view, i.e. a mathematical equivalence class.

Now, if the class gathers only one object, the equivalence relationship
does not make much sense...

In some cases, you need a stand-alone object. Fine, but you don't need
to define a class for that. Note that Ada allows you  to define
singleton arrays, tasks, and protected objects without an explicit type
to enforce that notion.

Some languages do not allow you to define an object unless it belongs to
a class; that's why you have to jump through complicated hoops to define
those "singleton classes", i.e. structures that are made to hold many
objects, but with appropriate design patterns to make sure there is only
one. It is simply not necessary in Ada. Note that it /can/ be
implemented like in other languages, and I don't think it would be more
complicated - just that the (unnecessary in the Ada case) complication
shines more brightly.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada-Singleton-Why does it work like this?

[Georg Bauhaus]

patrick.gunia@googlemail.com schrieb:

> Still I don�t get how the unconstrained type limits the
> number of instances to 1.

It does, but outside package Singleton only.

The (<>) forces initialization.
The "limited" part prevents assignment (thus copying).
The type is private.

Any object to be created in whichever way must be
initialized because of (<>). Initialization is not
possible outside the package because Singleton_Type
has discriminants unknown outside the package.

Also, any object of the public Singleton_Type cannot be
assigned a new value (because it is limited).

The only place where objects of type Singleton_Type
can be created is where the full definition
of type Singleton_Type is visible.

The only way to get a reference to the object is
through function return_Single. This function
always returns the same access value, hence clients
of package Singleton always use the same (invisible)
object.

Re: Ada-Singleton-Why does it work like this?

[patrick.gunia]

On 25 Mrz., 12:10, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 25 Mar 2009 03:07:18 -0700 (PDT), patrick.gu...@googlemail.com
> wrote:
>
> > Maybe I´m getting something wrong, but from my point of view,
> > Singleton offers more possibilities than just the execution of some
> > code on elaboration of some module.I like the dynamic version Ludovic
> > described. It also offers the possibility to change the number of
> > instances later on and thus increases the adaptability.
>
> Sorry, but a singleton with more than one instance is not a singleton.

This is arguable. Gamma et al. tell explictily in their work, that it
´s one advantage of the Singleton-pattern that the number of creatable
instances can be fixed later on without major code changes. Thus I
think of the pattern more like a possibility to gain control over the
number of instantiations of a concrete class, not necessarily
restricted to one, though limited.


> > When you say
> > that Singleton isn´t necessary in Ada this might come from the fact
> > that it can´t be implemented as in other languages, though using such
> > a construct might increase readability of the code.
>
> No, it is rather so, that the problems solved in other languages using the
> singleton pattern, in Ada are solved using different patterns.
>
> There is a general note about software design patterns, that they usually
> indicate some language deficiency. If a language has a construct to express
> the idea behind the pattern, then it is not a pattern anymore. Pattern
> assumes some manual, yet routine work on the programmer side, which cannot
> be taken over by the language, because ...

This might be true for some simple patterns like Singleton, though I
think that most patterns solve problems which are language
independent, thus not aiming at a language deficiency. For example
patterns for using frameworks or letting different interfaces
communicate with each other. It seems to me that this is an
architectural question, not a language question.

Re: Ada-Singleton-Why does it work like this?

[Ludovic Brenta]

Patricj Gunia wrote on comp.lang.ada:
> It also offers the possibility to change the number of
> instances later on and thus increases the adaptability.

Please re-read that sentence. Do you really believe that increasing
the number of instances of a singleton is a feature? I call that a
bug!

--
Ludovic Brenta.

Re: Ada-Singleton-Why does it work like this?

[Georg Bauhaus]

patrick.gunia@googlemail.com schrieb:
> Yet another question, if my Singleton_Type is unconstrained, why does
> Ada allow creating Access-Types to unconstrained types allowing to
> access there record-properties, while not allowing to create an
> instance of Singleton_Type directly?

This is wrong, see below.

> if I declare a pointer in C++ I
> either have to create a new instance using "new" in heap-memory where
> the pointer points to or I have to use references and then let the
> pointer point to a reference.

Same in Ada. Although, you have to use "aliased" before an object
(or have an object that is implicitly aliased) if you want to use
C++::&.

> In both cases I first have to create an
> object and then let the pointer point to it.

Same in Ada.

> When I use access types
> in Ada in my example it�s possible to create a pointer to a class

Nitpick: You can't point to a class, only to objects.

> which can�t be instantiated, because it is unconstrained.

(Nitpick: you instantiate generic units, you create objects.)
Objects of type Singleton_Type can be created.
They cannot, however, be created outside the package Singleton.

HTH

Re: Ada-Singleton-Why does it work like this?

[Ludovic Brenta]

On Mar 25, 11:57 am, "patrick.gu...@googlemail.com"
<patrick.gu...@googlemail.com> wrote:
> Yet another question, if my Singleton_Type is unconstrained, why does
> Ada allow creating Access-Types to unconstrained types allowing to
> access there record-properties, while not allowing to create an
> instance of Singleton_Type directly? I thought that Ada demands a
> declaration of an instance before creating an Access-Type to access
> it? Maybe I´m mixing in C++, but if I declare a pointer in C++ I
> either have to create a new instance using "new" in heap-memory where
> the pointer points to or I have to use references and then let the
> pointer point to a reference. In both cases I first have to create an
> object and then let the pointer point to it. When I use access types
> in Ada in my example it´s possible to create a pointer to a class
> which can´t be instantiated, because it is unconstrained. Though it
> works to access the record-properties using the access-type. Could
> anyone tell me what I´m getting wrong concerning Ada?
>
> Thank you!

If you want to declare an access type, you do not need an instance;
you only need a type, which may be unconstrained:

type T (<>) is limited private;
type Access_T is access T; -- OK

If you want an access *value*, then you do need an object; either one
from a storage pool, or a pre-existing one:

Access_Value : Access_T := new T'(...);
-- storage pool. Possible only in the package declaring T, since T is
private.

Other_Access_Value : Access_T := Access_Value; -- possible anywhere

Neither Access_Value nor Other_Access_Value allow you to see the
components of T because T is private.

--
Ludovic Brenta.

Re: Ada-Singleton-Why does it work like this?

[patrick.gunia]

On 25 Mrz., 12:26, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> patrick.gu...@googlemail.com schrieb:
>
> > Still I don´t get how the unconstrained type limits the
> > number of instances to 1.
>
> It does, but outside package Singleton only.
>
> The (<>) forces initialization.
> The "limited" part prevents assignment (thus copying).
> The type is private.

Now I´m slowly getting the point of this...it´s the combination of
private, limited and the unconstrained type. If I don´t declare it as
private and limited, I would be able to instantiate it, because it is
visible outside the package? In this case I would be able to assign a
value when declaring an instance and thus I would of course be able to
create as many instances as I want to? Is this right?

Re: Ada-Singleton-Why does it work like this?

[patrick.gunia]

On 25 Mrz., 12:46, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> On Mar 25, 11:57 am, "patrick.gu...@googlemail.com"
>
>
>
>
>
> <patrick.gu...@googlemail.com> wrote:
> > Yet another question, if my Singleton_Type is unconstrained, why does
> > Ada allow creating Access-Types to unconstrained types allowing to
> > access there record-properties, while not allowing to create an
> > instance of Singleton_Type directly? I thought that Ada demands a
> > declaration of an instance before creating an Access-Type to access
> > it? Maybe I´m mixing in C++, but if I declare a pointer in C++ I
> > either have to create a new instance using "new" in heap-memory where
> > the pointer points to or I have to use references and then let the
> > pointer point to a reference. In both cases I first have to create an
> > object and then let the pointer point to it. When I use access types
> > in Ada in my example it´s possible to create a pointer to a class
> > which can´t be instantiated, because it is unconstrained. Though it
> > works to access the record-properties using the access-type. Could
> > anyone tell me what I´m getting wrong concerning Ada?
>
> > Thank you!
>
> If you want to declare an access type, you do not need an instance;
> you only need a type, which may be unconstrained:
>
> type T (<>) is limited private;
> type Access_T is access T; -- OK
>
> If you want an access *value*, then you do need an object; either one
> from a storage pool, or a pre-existing one:
>
> Access_Value : Access_T := new T'(...);
> -- storage pool. Possible only in the package declaring T, since T is
> private.
>
> Other_Access_Value : Access_T := Access_Value; -- possible anywhere
>
> Neither Access_Value nor Other_Access_Value allow you to see the
> components of T because T is private.
>
> --
> Ludovic Brenta.

Alright, I mixed this up, you´re right. Slowly all pieces make sense
to me and now I´m starting to get the differences and why the
Singleton-implementation works...
Thank you for your help!

Re: Ada-Singleton-Why does it work like this?

[Ludovic Brenta]

Patrick Gunia wrote on comp.lang.ada:
> Dmitry A. Kazakov wrote:
> > Sorry, but a singleton with more than one instance is not a singleton.
>
> This is arguable. Gamma et al. tell explictily in their work, that it
> ´s one advantage of the Singleton-pattern that the number of creatable
> instances can be fixed later on without major code changes. Thus I
> think of the pattern more like a possibility to gain control over the
> number of instantiations of a concrete class, not necessarily
> restricted to one, though limited.

Then do not call this a Singleton; call it a
Bounded_Pool_Of_Instances. And in Ada, you still do not need tagged
types or public access types to implement this pattern:

package Pool_Of_Instances is
   type Handle (<>) is private;
   Null_Handle : constant Handle;
   function Next_Available return Handle;
   procedure Operate (On : in Handle);
   procedure Return (H : in out Handle);
   Pool_Exhausted : exception;
private
   type T;
   type Handle is access all T; -- note: the access type is private
   Null_Handle : constant Handle := null;
end Pool_Of_Instances;

package body Pool_Of_Instances is
   type T is record ... end record;
   N : constant := 10;
  Instances : array (1 .. N) of aliased T;
  Available : array (1 .. N) of Boolean := (others => True);

  function Next_Available return Handle is
  begin
      for J in Available'Range loop
         if Available (J) then
            Available (J) := False;
            return Instances (J)'Access;
         end if;
      end loop;
      raise Pool_Exhausted;
  end Next_Available;

   procedure Return (H : in out Handle) is
   begin
      H := Null_Handle;
   end Return;

end Pool_Of_Instances;

The above pattern can be extended to do reference counting and
deallocate unused instances, thereby making some slots available
again. For that you'd need to make Handle controlled:

package Pool_Of_Instances is
   -- as above
private
   type T;
   type Access_T is access all T;
   type Handle is new Ada.Finalization.Controlled with record
      Instance : Access_T;
   end record;
   overriding procedure Initialize (H : in out Handle);
   overriding procedure Adjust (H : in out Handle);
   overriding procedure Finalize (H : in out Handle);
end Pool_Of_Instances;

The Instance would contain the reference count; Initialize, Adjust and
Finalize would manage it. See http://www.adaic.com/learn/tech/safe_ptr.html
for inspiration.

--
Ludovic Brenta.

Re: Ada-Singleton-Why does it work like this?

[patrick.gunia]

> If you want to declare an access type, you do not need an instance;
> you only need a type, which may be unconstrained:
>
> type T (<>) is limited private;
> type Access_T is access T; -- OK
>
> If you want an access *value*, then you do need an object; either one
> from a storage pool, or a pre-existing one:
>
> Access_Value : Access_T := new T'(...);
> -- storage pool. Possible only in the package declaring T, since T is
> private.
>
> Other_Access_Value : Access_T := Access_Value; -- possible anywhere
>
> Neither Access_Value nor Other_Access_Value allow you to see the
> components of T because T is private.

I´m currently trying to formulate some rules for using Ada myself,
trying to explain the concepts which are used. I got one last question
concerning the box-operator (<>) in this particular context.
It declares a type to be unconstrained, which means, that it needs to
be initialized. I only found this construction together with generic
types, for example here: http://en.wikibooks.org/wiki/Ada_Programming/Generics
When I try to define a sort-routine I can use this generic form to
state, that discrete types may be used as input for such a routine.
But as I don´t use this construct together with the keyword generic, I
simply don´t get the meaning of (<>) in my Singleton-context. Do I say
that the type I declare is a discrete type? And what would I have to
do to use this type if it wasn´t limited and private?

Thank you!

Re: Ada-Singleton-Why does it work like this?

[Ludovic Brenta]

On Mar 25, 3:10 pm, "patrick.gu...@googlemail.com"
<patrick.gu...@googlemail.com> wrote:
> > If you want to declare an access type, you do not need an instance;
> > you only need a type, which may be unconstrained:
>
> > type T (<>) is limited private;
> > type Access_T is access T; -- OK
>
> > If you want an access *value*, then you do need an object; either one
> > from a storage pool, or a pre-existing one:
>
> > Access_Value : Access_T := new T'(...);
> > -- storage pool. Possible only in the package declaring T, since T is
> > private.
>
> > Other_Access_Value : Access_T := Access_Value; -- possible anywhere
>
> > Neither Access_Value nor Other_Access_Value allow you to see the
> > components of T because T is private.
>
> I´m currently trying to formulate some rules for using Ada myself,
> trying to explain the concepts which are used. I got one last question
> concerning the box-operator (<>) in this particular context.
> It declares a type to be unconstrained, which means, that it needs to
> be initialized. I only found this construction together with generic
> types, for example here:http://en.wikibooks.org/wiki/Ada_Programming/Generics
> When I try to define a sort-routine I can use this generic form to
> state, that discrete types may be used as input for such a routine.
> But as I don´t use this construct together with the keyword generic, I
> simply don´t get the meaning of (<>) in my Singleton-context. Do I say
> that the type I declare is a discrete type? And what would I have to
> do to use this type if it wasn´t limited and private?
>
> Thank you!

Please re-read the wikibook chapter on generics; there is a difference
between:

generic
   type T1 is <>; -- any discrete type

and

generic
   type T2 (<>) is private; -- any type with or without discriminants

Formally, T2 is declared to have "unknown discriminants".  This is
also the case of the singleton type. Because, to the outside world, it
has unknown discriminants, it is unconstrained. The full view of the
type (in the private part of the package) may or may not specify
discriminants.

--
Ludovic Brenta.

Re: Ada-Singleton-Why does it work like this?

[Robert A Duff]

"patrick.gunia@googlemail.com" <patrick.gunia@googlemail.com> writes:

> This might be true for some simple patterns like Singleton, though I
> think that most patterns solve problems which are language
> independent, thus not aiming at a language deficiency. For example
> patterns for using frameworks or letting different interfaces
> communicate with each other. It seems to me that this is an
> architectural question, not a language question.

More than half of the design patterns in Gamma et al are unnecessary in
some language (in some cases, in Ada), either because they are supported
directly by the language, or because they are so trivial that you
wouldn't bother calling them a "pattern".

- Bob

Re: Ada-Singleton-Why does it work like this?

[Adam Beneschan]

On Mar 25, 7:40 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> On Mar 25, 3:10 pm, "patrick.gu...@googlemail.com"
>
>
>
> <patrick.gu...@googlemail.com> wrote:
> > > If you want to declare an access type, you do not need an instance;
> > > you only need a type, which may be unconstrained:
>
> > > type T (<>) is limited private;
> > > type Access_T is access T; -- OK
>
> > > If you want an access *value*, then you do need an object; either one
> > > from a storage pool, or a pre-existing one:
>
> > > Access_Value : Access_T := new T'(...);
> > > -- storage pool. Possible only in the package declaring T, since T is
> > > private.
>
> > > Other_Access_Value : Access_T := Access_Value; -- possible anywhere
>
> > > Neither Access_Value nor Other_Access_Value allow you to see the
> > > components of T because T is private.
>
> > I´m currently trying to formulate some rules for using Ada myself,
> > trying to explain the concepts which are used. I got one last question
> > concerning the box-operator (<>) in this particular context.
> > It declares a type to be unconstrained, which means, that it needs to
> > be initialized. I only found this construction together with generic
> > types, for example here:http://en.wikibooks.org/wiki/Ada_Programming/Generics
> > When I try to define a sort-routine I can use this generic form to
> > state, that discrete types may be used as input for such a routine.
> > But as I don´t use this construct together with the keyword generic, I
> > simply don´t get the meaning of (<>) in my Singleton-context. Do I say
> > that the type I declare is a discrete type? And what would I have to
> > do to use this type if it wasn´t limited and private?
>
> > Thank you!
>
> Please re-read the wikibook chapter on generics; there is a difference
> between:
>
> generic
>    type T1 is <>; -- any discrete type

should be

  generic
     type T1 is (<>);

                            -- Adam

Re: Ada-Singleton-Why does it work like this?

[patrick.gunia]

> generic
>    type T2 (<>) is private; -- any type with or without discriminants
>
> Formally, T2 is declared to have "unknown discriminants".  This is
> also the case of the singleton type. Because, to the outside world, it
> has unknown discriminants, it is unconstrained. The full view of the
> type (in the private part of the package) may or may not specify
> discriminants.
>
> --
> Ludovic Brenta.

I think that this is what made me stumble. The fact that it simply
states, that it´s unknown wether or not the type has discriminants and
that the private part can or cannot use such discriminants. These are
concepts, I haven´t seen before when using other languages. And
because the package body knows the concrete structure of my
Singleton_Type, it also knows that a discriminant is not defined and
thus not necessary for creating new variables of my type. That is why I
´m able to create a Singleton instance within the package body. Is
this right? If so, then I finally got it...

Re: Ada-Singleton-Why does it work like this?

[Georg Bauhaus]

patrick.gunia@googlemail.com schrieb:

> because the package body knows the concrete structure of my
> Singleton_Type, it also knows that a discriminant is not defined and
> thus not necessary for creating new variables of my type. That is why I
> �m able to create a Singleton instance within the package body. Is
> this right? If so, then I finally got it...


Almost, yes. The full view of the type in the
private part may have _known_ discriminants.
(It may have zero or more discriminants.)
If it has one you can create objects of the type
just as well because you can supply a value for the
discriminant, thereby adding the necessary constraint.

package body ...

   Var: T(Some_Dicriminant => 10);

Re: Ada-Singleton-Why does it work like this?

[sjw]

On Mar 24, 8:47 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> patrick.gu...@googlemail.com wrote:
> > Hi all,
> > I´m currently working on implementing several design patterns in Ada,
> > and I found some code concerning the Singleton-pattern when searching
> > through the posts of this group. I used this code and it all worked as
> > expected. My problem is, that I don´t ave any idea, why it does...here
> > is my code:
>
> > package Singleton is
>
> >    type Singleton_Type (<>) is tagged limited private;
> >    type Singleton_Access is access all Singleton_Type;
>
> >    function return_Single return Singleton_Access;
>
> >    procedure setValues(input : in out Singleton_Access; valueIN :
> > Integer; valueIN2 : Integer);
> >    procedure print_something(input : Singleton_Access);
>
> >    private
> >    type Singleton_Type is tagged limited record
> >            value : Integer;
> >            value2 : Integer;
> >    end record;
>
> > end Singleton;
>
> This is a very poor solution to the problem. A much simpler solution is
>
> package Singleton is
>     procedure Set (Value_1 : in Integer; Value_2 : in Integer);
>
>     procedure Print;
> end Singleton;

Usually the application problem is to do something (eg print stuff)
and there's a side note that there's only one printer.

We could decide to apply the singleton-in-package pattern above to
ensure the limit is met.

In general, though, having only one printer isn't an integral part of
the application problem, and it'll be a real pain when it turns out
you need to add one. Better to be general about it.

My code generator allowed for singletons (no visible creation/deletion
operations, "instance" operations don't need a This parameter, ...)
because I thought it would be useful, but in fact it's been a feature
I deeply regret; it introduces inconsistency and irregularity. Now I
prefer to specify that there is a bounded number of instances and make
the bounds 0..1.

Re: Ada-Singleton-Why does it work like this?

[Martin]

On 25 Mar, 09:30, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 24 Mar 2009 17:10:11 -0700 (PDT), Martin wrote:
> > On Mar 24, 8:47 pm, "Jeffrey R. Carter"
> >> This is a very poor solution to the problem. A much simpler solution is
>
> >> package Singleton is
> >>     procedure Set (Value_1 : in Integer; Value_2 : in Integer);
>
> >>     procedure Print;
> >> end Singleton;
>
> > But you can not derive a class from this:
>
> Firstly you can. There are child packages in Ada, they are equivalent to
> derivation.
>
> Secondly, you may not because it is a singleton. A derived variant would be
> meaningless without making an instance of, which would be *another*
> instance of now non-singleton.

Unless you use the "tagged type" version...and that would be ok, as a
type is not an object. So you would have something like:

package Singletons is
   type Singleton ...;
   function Get_Instance return Singleton;
end Singletons;

package Singletons.Thread_Safe is
   type Thread_Safe_Singleton is new Singleton ...;
   function Get_Instance return Thread_Safe_Singleton;
end Singletons.Thread_Safe;

But only one object of either of these types could be instantiated.

Cheers
-- Martin

Re: Ada-Singleton-Why does it work like this?

[Martin]

On 25 Mar, 11:17, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> I think there is a contradiction between "class" and "singleton". The
> term "class" is used, because it includes a set of objects that are
> equivalent for some point of view, i.e. a mathematical equivalence class.
>
> Now, if the class gathers only one object, the equivalence relationship
> does not make much sense...

It is a set - it just has a single member.

I think Singleton-as-a-type is useful if and only if you wish to
retain behavours you can acheive with other classes, e.g it may be
useful to mix in "stream-ability" or even polymorphism - e.g. you know
you can only have a single modem in your system but you may need to
have different modems (e.g. Hayes v. Alcatel. v. whoever).

Now in Ada we are used to doing that sort of thing via package renames
and compilation options. But perhaps that isn't an option in system
where modems can be replaced between power-down/power-ups.

Again, we used to seeing a different style of solving that problem in
Ada but that's not to say that solutions used in other languages
shouldn't be looked at on their own merits.

Perhaps the Patterns Working Group of the ACM could provide classic-
Ada-style v. GoF-style presentation? Or is it really that defunct?

Cheers
-- Martin

Re: Ada-Singleton-Why does it work like this?

[Dmitry A. Kazakov]

On Thu, 26 Mar 2009 01:55:46 -0700 (PDT), Martin wrote:

> On 25 Mar, 09:30, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 24 Mar 2009 17:10:11 -0700 (PDT), Martin wrote:
>>> On Mar 24, 8:47�pm, "Jeffrey R. Carter"
>>>> This is a very poor solution to the problem. A much simpler solution is
>>
>>>> package Singleton is
>>>> � � procedure Set (Value_1 : in Integer; Value_2 : in Integer);
>>
>>>> � � procedure Print;
>>>> end Singleton;
>>
>>> But you can not derive a class from this:
>>
>> Firstly you can. There are child packages in Ada, they are equivalent to
>> derivation.
>>
>> Secondly, you may not because it is a singleton. A derived variant would be
>> meaningless without making an instance of, which would be *another*
>> instance of now non-singleton.
> 
> Unless you use the "tagged type" version...and that would be ok, as a
> type is not an object. So you would have something like:
> 
> package Singletons is
>    type Singleton ...;
>    function Get_Instance return Singleton;
> end Singletons;
> 
> package Singletons.Thread_Safe is
>    type Thread_Safe_Singleton is new Singleton ...;
>    function Get_Instance return Thread_Safe_Singleton;
> end Singletons.Thread_Safe;
> 
> But only one object of either of these types could be instantiated.

This highlights the point. "Singletonness" is not a property of the type
used to implement it. So the pattern is all wrong. The type itself is not a
singleton, you only use it as if it were one. A proper design would be,
IMO:

package Singletons is
   procedure Do_Things;
private
   type Resusable_Object ...; -- Do not expose it
   procedure Implement_Do_Things (Instance : in out Resusable_Object);
end Singletons;

package body Singletons is
   Single : Resusable_Object;

   procedure Do_Things is
   begin
       Implement_Do_Things (Single);
   end Do_Things;
   ...
end Singletons;

package Singletons.Thread_Safe is
   procedure Do_Safe_Things;
private
   type Thread_Safe_Object is new Resusable_Object;
   overriding
      procedure Implement_Do_Things (Instance : in out Thread_Safe_Object);
end Singletons.Thread_Safe;

It is a question whether Resusable_Object should be put into the package
Singletons. Likely it could be used elsewhere not as a singleton. So in the
end, we still have the classic Ada design pattern of singletons:

with Anything_I_Need_To_Implement_This;

package Singletons is
   procedure Do_Things;
end Singletons;

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

Re: Ada-Singleton-Why does it work like this?

[Maciej Sobczak]

On 26 Mar, 10:28, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> This highlights the point. "Singletonness" is not a property of the type
> used to implement it.

Depends. The type involves not only the set of possible states, but
also the set of possible operations. Is the creation as an operation
part of this set?
If creation belongs to the set of operations of some type, then
"singletonness" is obviously a property of the type.
If, on the other hand, creation does not belong to this set, then
indeed these concepts are orthogonal.

Can you defend the idea that creation does not belong to the type?

> So the pattern is all wrong.

Or not - maybe it is a way to express some property of the *type* that
cannot be expressed due to the limitations in the language?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Ada-Singleton-Why does it work like this?

[Georg Bauhaus]

Maciej Sobczak schrieb:

> Or not - maybe it is a way to express some property of the *type* that
> cannot be expressed due to the limitations in the language?

If "type" means the tuple ({values}, operations), then these
should be a few types where |{values}| = 1.

package One is

   type Foo is (X);
   type Bar is (Y);

   type This_Type_Has_One_Value is
      record
         Comp_1 : Foo := X;
         Comp_2 : Bar := Y;
      end record;

end One;

Re: Ada-Singleton-Why does it work like this?

[Dmitry A. Kazakov]

On Thu, 26 Mar 2009 06:39:26 -0700 (PDT), Maciej Sobczak wrote:

> On 26 Mar, 10:28, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> This highlights the point. "Singletonness" is not a property of the type
>> used to implement it.
> 
> Depends. The type involves not only the set of possible states, but
> also the set of possible operations. Is the creation as an operation
> part of this set?

No, creation is not an operation.

Operations are defined on values. A singleton is a variable that can take
different values changed by applying corresponding operations. The property
of being singleton is one of the variable (object).

> Can you defend the idea that creation does not belong to the type?

I think I can. Creation cannot be expressed in terms of values of the type.
As an example consider integer. There is no integer operation that creates
values. In fact, integer values exist outside the program, they always
existed before and will exist after any program being written or run.
Obviously + does not create a new 4 when 2 is added to 2. Similarly, there
is no integer subprogram that creates an integer object (like a variable).
That is a prerogative of the compiler which inserts some magic object
creation stuff as necessary. This thing is called "constructor." Functions
are not constructors, they return "existing" objects. Even newly introduced
Pickwickian functions in Ada 2005 do so. That's why return-statement was
invented.

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

Re: Ada-Singleton-Why does it work like this?

[Dmitry A. Kazakov]

On Thu, 26 Mar 2009 15:07:39 +0100, Georg Bauhaus wrote:

> Maciej Sobczak schrieb:
> 
>> Or not - maybe it is a way to express some property of the *type* that
>> cannot be expressed due to the limitations in the language?
> 
> If "type" means the tuple ({values}, operations), then these
> should be a few types where |{values}| = 1.

No, singleton does not mean "one value." It means "one object." For
example, already mentioned standard printer, or, say, system clock. They
are singletons. The latter one has an infinitely uncountable number of
values (states).

(OK, in quantum theory, clock might be countable, nevertheless, it is far
more than 1)

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

Re: Ada-Singleton-Why does it work like this?

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Thu, 26 Mar 2009 15:07:39 +0100, Georg Bauhaus wrote:
> 
>> Maciej Sobczak schrieb:
>>
>>> Or not - maybe it is a way to express some property of the *type* that
>>> cannot be expressed due to the limitations in the language?
>> If "type" means the tuple ({values}, operations), then these
>> should be a few types where |{values}| = 1.
> 
> No, singleton does not mean "one value."

Right, however, how can a type bedefined to have "one object"
if the type has a set of values of cardinality > 1?
That is, can "singleton" be made a property of a type
other than programmatically?

Re: Ada-Singleton-Why does it work like this?

[Dmitry A. Kazakov]

On Thu, 26 Mar 2009 16:22:51 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Thu, 26 Mar 2009 15:07:39 +0100, Georg Bauhaus wrote:
>> 
>>> Maciej Sobczak schrieb:
>>>
>>>> Or not - maybe it is a way to express some property of the *type* that
>>>> cannot be expressed due to the limitations in the language?
>>> If "type" means the tuple ({values}, operations), then these
>>> should be a few types where |{values}| = 1.
>> 
>> No, singleton does not mean "one value."
> 
> Right, however, how can a type bedefined to have "one object"
> if the type has a set of values of cardinality > 1?

Type cannot be, because the semantics "it has one instance" cannot be
expressed in terms of the type. There is no operation or value of the type
that may reflect this semantics. It is a contract on somebody who uses the
type in order to create instances of. Since creation is neither operation
nor a value there is no way to bind it to a type.

For example. Typically there is a factory used to create the instance of
the singleton's type T. But the factory is another object of a different
type F. So the semantics that T has one instance is expressed by the type
F, rather than T.

> That is, can "singleton" be made a property of a type
> other than programmatically?

My position that it cannot be.

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

Re: Ada-Singleton-Why does it work like this?

[Maciej Sobczak]

On 26 Mar, 15:28, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > Can you defend the idea that creation does not belong to the type?
>
> I think I can. Creation cannot be expressed in terms of values of the type.
[...]

Makes sense.
What about... constructors? I mean the real ones.

In other mainstream languages (you know, those with curly braces ;-) )
and let's say in Ada 2015 as well, constructors are defined
*syntactically* within the type. If we consider the object creation as
something that does not belong to the type, then can we say that
having constructors in a type definition is just a convenient
distortion and not a clear expression of the *semantic* reality, where
constructor should be defined as the entity that is external to the
type?

Something like:

class X
{
public:
    void doThis();
    void doThat();
private:
    // ...
};

// imaginary constructor of type X
X()
{
    // make up the state of new object
}

What is "inside" or "outside" might have no sense in Ada, but in Ada
terms the problem can be expressed as whether constructors should be
primitive operations of the given type.

Just thinking aloud.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Ada-Singleton-Why does it work like this?

[Dmitry A. Kazakov]

On Thu, 26 Mar 2009 15:00:52 -0700 (PDT), Maciej Sobczak wrote:

> On 26 Mar, 15:28, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Can you defend the idea that creation does not belong to the type?
>>
>> I think I can. Creation cannot be expressed in terms of values of the type.
> [...]
> 
> Makes sense.
> What about... constructors? I mean the real ones.

The real ones are magical things.

> In other mainstream languages (you know, those with curly braces ;-) )
> and let's say in Ada 2015 as well, constructors are defined
> *syntactically* within the type.

The "constructors" of C++ are not constructors, but user-defined procedures
called from the real constructor at certain stages of object construction.
It is similar to Ada.Finalization.Initialize, but far better designed.
(Except than unavoidable in C++ nonsense of the object type mutating during
construction.)

> If we consider the object creation as
> something that does not belong to the type, then can we say that
> having constructors in a type definition is just a convenient
> distortion and not a clear expression of the *semantic* reality, where
> constructor should be defined as the entity that is external to the
> type?
> 
> Something like:
> 
> class X
> {
> public:
>     void doThis();
>     void doThat();
> private:
>     // ...
> };
> 
> // imaginary constructor of type X
> X()
> {
>     // make up the state of new object
> }
> 
> What is "inside" or "outside" might have no sense in Ada, but in Ada
> terms the problem can be expressed as whether constructors should be
> primitive operations of the given type.

In my view neither the constructor nor the user-defined construction hook
are primitive operations in traditional sense. That is, a primitive
operation is defined on a class of types and its implementation has a
separate body for each type from the class. I.e. f acts on T'Class and for
each type S from the class T, there is a body S.f. This body is either
inherited and then composed with a type conversion (S.f = S_from_T o T.f o
T_from_S) or else is overridden by the user.

A user-defined construction hook of T is neither inherited by S, nor
overridden by the user. The "real constructor" of S calls the hook of T
upon construction of S before it does the hook of S. That is a different
way of procedural composition. It is additive. (Of course, when
constructing hook of T is called on S, S is first converted to T and then
back to S. This is a mere view conversion for by-reference types.)

We could imagine some generalized model of a primitive operation in which a
body of f for the type T would consist of some prologue, overridable part
and epilogue. A derived type S would be able to extend the prologue and/or
epilogue and to replace the overridable part. (This could be useful if you
wanted to do transaction or concurrent stuff transparently. For example,
the prologue could grab a lock, the epilogue would release it. The
overridable part would do things.)

However, even in this generalized model I would keep
constructing/destructing hooks separate from primitive operations in order
to prevent them called elsewhere than from compiler-generated constructors
and destructors. Just for safety reasons. C++ people did it right, when
they forbade explicit calls to T::T() and T::~T().

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

Re: Ada-Singleton-Why does it work like this?

[Jacob Sparre Andersen]

"patrick.gunia@googlemail.com" <patrick.gunia@googlemail.com> wrote:

> I used a tagged type because I wanted to use the Singleton
> implementation as bsae class for other classes with more
> functionality though sharing the singleton behaviour.

That's a very complicated way of creating singletons, unless of course
that you actually have some operations which should work on your whole
class of singletons.

In general, it is easier to write:

   package Single_Car is
      procedure Start;
      procedur Stop;
   end Single_Car;

   package Single_Plane is
      procedure Start;
      procedur Stop;
   end Single_Plane;

than it is to write:

   package Singleton is
      type Instance (<>) is tagged limited private;
      ...
   private
      ...
   end Singleton;

   package Single_Car is
      type Instance is new Singleton.Instance with private;
      procedure Start (Item : in out Instance);
      procedure Stop (Item : in out Instance);
   private
      ...
   end Single_Car;

   package Single_Plane is
      type Instance is new Singleton.Instance with private;
      procedure Start (Item : in out Instance);
      procedure Stop (Item : in out Instance);
   private
      ...
   end Single_Plane;

Greetings,

Jacob
-- 
"Very small. Go to sleep" -- monster (not drooling)