Smalltalk › Pharo › Pharo Smalltalk Users

singleton trait

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Siemen Baader

singleton trait

Is there a trait to quickly create singletons in Pharo, along the way of the Ruby Singleton mixin?

https://ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html

(and ideally also observer/observable, which I am going to need next..)

-- Siemen

CyrilFerlicot

Re: singleton trait

On 19/01/2017 11:23, Siemen Baader wrote:
> Is there a trait to quickly create singletons in Pharo, along the way of
> the Ruby Singleton mixin?
>
> https://ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html
>
> (and ideally also observer/observable, which I am going to need next..)
>
> -- Siemen

Hi!

Singleton in Smalltalk are really easy so there is no Trait.

You just need a class variable #UniqueInstance and those methods:

current
"Can also be named #default or #instance"
^ UniqueInstance
ifNil: [ UniqueInstance := self basicNew; initialize; yourself ]

new
^ self error: 'I am a Singleton. Use current to get my instance or
reset my instance with a new project. Maybe explain why there is a
Singleton because we should avoid them if possible.'

Now for the observer pattern you have the Announcement framework in Pharo.

I don't really have the time to explain but I think there is some doc on
internet and on the help browser of Pharo. I found this:
http://pharo.gemtalksystems.com/book/LanguageAndLibraries/announcements/
(I did not read it so I don't know what it's worth)

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

signature.asc (817 bytes) Download Attachment

Sven Van Caekenberghe-2

Re: singleton trait

The Traits would be cool to standardise the behaviour and to mark it as such (implicit documentation), however, Traits cannot add instance/class variables IIUC, that limits what they can do (and would make it more than one step).

> On 19 Jan 2017, at 11:33, Cyril Ferlicot D. <[hidden email]> wrote:
>
> On 19/01/2017 11:23, Siemen Baader wrote:
>> Is there a trait to quickly create singletons in Pharo, along the way of
>> the Ruby Singleton mixin?
>>
>> https://ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html
>>
>> (and ideally also observer/observable, which I am going to need next..)
>>
>> -- Siemen
>
> Hi!
>
> Singleton in Smalltalk are really easy so there is no Trait.
>
> You just need a class variable #UniqueInstance and those methods:
>
> current
> "Can also be named #default or #instance"
> ^ UniqueInstance
> ifNil: [ UniqueInstance := self basicNew; initialize; yourself ]
>
> new
> ^ self error: 'I am a Singleton. Use current to get my instance or
> reset my instance with a new project. Maybe explain why there is a
> Singleton because we should avoid them if possible.'
>
>
> Now for the observer pattern you have the Announcement framework in Pharo.
>
> I don't really have the time to explain but I think there is some doc on
> internet and on the help browser of Pharo. I found this:
> http://pharo.gemtalksystems.com/book/LanguageAndLibraries/announcements/
> (I did not read it so I don't know what it's worth)
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>

Denis Kudriashov

Re: singleton trait

2017-01-19 11:37 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:

The Traits would be cool to standardise the behaviour and to mark it as such (implicit documentation), however, Traits cannot add instance/class variables IIUC, that limits what they can do (and would make it more than one step).

We could have statefull traits in future

Siemen Baader

Re: singleton trait

In reply to this post by Sven Van Caekenberghe-2

On Thu, Jan 19, 2017 at 11:37 AM, Sven Van Caekenberghe <[hidden email]> wrote:

The Traits would be cool to standardise the behaviour and to mark it as such (implicit documentation)

Exactly.

, however, Traits cannot add instance/class variables IIUC, that limits what they can do (and would make it more than one step).

Ok. So that's the difference between a Ruby mixin and a trait. That's a shame, I think what Ruby does with mixins is really nice because it a) results in less code to test, and b) makes hineritance chains more semantic - you only inherit to model spcialization, not to reuse features.

Cyril, many thanks! I know how to implement it and it is true that it is not much, but I had hoped to eliminate the code (and tests!) and use a standard feature if possible ;)

-- Siemen

> On 19 Jan 2017, at 11:33, Cyril Ferlicot D. <[hidden email]> wrote:
>
> On 19/01/2017 11:23, Siemen Baader wrote:
>> Is there a trait to quickly create singletons in Pharo, along the way of
>> the Ruby Singleton mixin?
>>
>> https://ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html
>>
>> (and ideally also observer/observable, which I am going to need next..)
>>
>> -- Siemen
>
> Hi!
>
> Singleton in Smalltalk are really easy so there is no Trait.
>
> You just need a class variable #UniqueInstance and those methods:
>
> current
> "Can also be named #default or #instance"
> ^ UniqueInstance
> ifNil: [ UniqueInstance := self basicNew; initialize; yourself ]
>
> new
> ^ self error: 'I am a Singleton. Use current to get my instance or
> reset my instance with a new project. Maybe explain why there is a
> Singleton because we should avoid them if possible.'
>
>
> Now for the observer pattern you have the Announcement framework in Pharo.
>
> I don't really have the time to explain but I think there is some doc on
> internet and on the help browser of Pharo. I found this:
> http://pharo.gemtalksystems.com/book/LanguageAndLibraries/announcements/
> (I did not read it so I don't know what it's worth)
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>

Siemen Baader

Re: singleton trait

In reply to this post by CyrilFerlicot

On Thu, Jan 19, 2017 at 11:33 AM, Cyril Ferlicot D. <[hidden email]> wrote:

You just need a class variable #UniqueInstance and those methods:

current
"Can also be named #default or #instance"
^ UniqueInstance
ifNil: [ UniqueInstance := self basicNew; initialize; yourself ]

Wouldn't a class instance variable be better? I want new singletons for every subclass. http://rmod-pharo-mooc.lille.inria.fr/MOOC/Slides/Week3/C019-W3S03-Basic-Variables.pdf

I would also have used super new, why BasicNew? But my wish to create subclasses seems to answer that already.

Thanks for your find-grained example, Cyril!

Siemen

jtuchel

Re: singleton trait

Am 19.01.17 um 15:51 schrieb Siemen Baader:

Wouldn't a class instance variable be better? I want new singletons for every subclass. http://rmod-pharo-mooc.lille.inria.fr/MOOC/Slides/Week3/C019-W3S03-Basic-Variables.pdf

I would also have used super new, why BasicNew? But my wish to create subclasses seems to answer that already.

super new might cause problems if you also want singletons for all subclasses and at least some of their subclasses and subclasses (1st generation) throw an exception in their #new.

CyrilFerlicot

Re: singleton trait

In reply to this post by Siemen Baader

On 19/01/2017 15:51, Siemen Baader wrote:
>
> Wouldn't a class instance variable be better? I want new singletons for
> every subclass.
> http://rmod-pharo-mooc.lille.inria.fr/MOOC/Slides/Week3/C019-W3S03-Basic-Variables.pdf

I use a class variable because I try to avoid a maximum the use of the
Singleton pattern. Most of the time it is wrongly used and it make
things harder to maintain in a long time. So I do not want a whole
hierarchy of Singleton :) (For some reasons about why Singletons are
evil you can easily find articles on internet. I looked quickly and
found this for example:
https://blogs.msdn.microsoft.com/scottdensmore/2004/05/25/why-singletons-are-evil/)

>
> I would also have used super new, why BasicNew? But my wish to create
> subclasses seems to answer that already.
>

When I do Singletons I change the new method to raise an error but I let
the developer use #basicNew in order to not forbid him to create a
second class if he knows what he's doing. With that we can test the
singleton with another instance that the one the application use.

> Thanks for your find-grained example, Cyril!
>

You're welcome :)

> Siemen

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

signature.asc (817 bytes) Download Attachment

Siemen Baader

Re: singleton trait

In reply to this post by Siemen Baader

On Thu, Jan 19, 2017 at 3:51 PM, Siemen Baader <[hidden email]> wrote:

On Thu, Jan 19, 2017 at 11:33 AM, Cyril Ferlicot D. <[hidden email]> wrote:

You just need a class variable #UniqueInstance and those methods:

current
"Can also be named #default or #instance"
^ UniqueInstance
ifNil: [ UniqueInstance := self basicNew; initialize; yourself ]

Actually this should have been: (no `;` between basicNew and initialize).

^ currentInstance

ifNil: [ currentInstance := self basicNew

initialize;

yourself ]

This is not a problem. But it illustrates that this would be nice to have it unit tested separately and mixed in with a trait/mixin to avoid the risk of manual errors in what in the end is an already solved problem - if one wants singletons, of course.

Siemen

Wouldn't a class instance variable be better? I want new singletons for every subclass. http://rmod-pharo-mooc.lille.inria.fr/MOOC/Slides/Week3/C019-W3S03-Basic-Variables.pdf

I would also have used super new, why BasicNew? But my wish to create subclasses seems to answer that already.

Thanks for your find-grained example, Cyril!

Siemen

stepharong

Re: singleton trait

In reply to this post by Siemen Baader

Pay attention that Singleton should not be about access but time.

If you can by adding on instance variable avoid to need a singleton then it means that it was not a singleton.

A singleton is often:

you **CANNOT** have two instances at the same time.

Many people do not use well singleton so watch out.

Stef

On Thu, 19 Jan 2017 11:23:21 +0100, Siemen Baader <[hidden email]> wrote:

Is there a trait to quickly create singletons in Pharo, along the way of the Ruby Singleton mixin?

https://ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html

(and ideally also observer/observable, which I am going to need next..)

-- Siemen

Using Opera's mail client: http://www.opera.com/mail/

Peter Uhnak

Re: singleton trait

On Sat, Jan 21, 2017 at 11:19:24AM +0100, stepharong wrote:
> Pay attention that Singleton should not be about access but time.
>
> If you can by adding on instance variable avoid to need a singleton
> then it means that it was not a singleton.
>
> A singleton is often:
> you **CANNOT** have two instances at the same time.
>
> Many people do not use well singleton so watch out.

We have several variations of singletons in the Pharo codebase, some of which do allow multiple instances, some of which don't. But they are differentiated by names.

https://www.peteruhnak.com/blog/2015/12/06/singleton-variations/

Peter

>
> Stef
>
> On Thu, 19 Jan 2017 11:23:21 +0100, Siemen Baader
> <[hidden email]> wrote:
>
> >Is there a trait to quickly create singletons in Pharo, along the
> >way of the Ruby Singleton mixin?
> >
> >https://ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html
> >
> >(and ideally also observer/observable, which I am going to need next..)
> >
> >-- Siemen
>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/

Sven Van Caekenberghe-2

Re: singleton trait

> On 21 Jan 2017, at 11:59, Peter Uhnak <[hidden email]> wrote:
>
> On Sat, Jan 21, 2017 at 11:19:24AM +0100, stepharong wrote:
>> Pay attention that Singleton should not be about access but time.
>>
>> If you can by adding on instance variable avoid to need a singleton
>> then it means that it was not a singleton.
>>
>> A singleton is often:
>> you **CANNOT** have two instances at the same time.
>>
>> Many people do not use well singleton so watch out.
>
> We have several variations of singletons in the Pharo codebase, some of which do allow multiple instances, some of which don't. But they are differentiated by names.
>
> https://www.peteruhnak.com/blog/2015/12/06/singleton-variations/

That's a good summary, thanks Peter.

> Peter
>
>>
>> Stef
>>
>> On Thu, 19 Jan 2017 11:23:21 +0100, Siemen Baader
>> <[hidden email]> wrote:
>>
>>> Is there a trait to quickly create singletons in Pharo, along the
>>> way of the Ruby Singleton mixin?
>>>
>>> https://ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html
>>>
>>> (and ideally also observer/observable, which I am going to need next..)
>>>
>>> -- Siemen
>>
>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>

stepharong

Re: singleton trait

In reply to this post by Peter Uhnak

Yes I like your blog entry.
But my point is orthogonal :)

> On Sat, Jan 21, 2017 at 11:19:24AM +0100, stepharong wrote:
>> Pay attention that Singleton should not be about access but time.
>>
>> If you can by adding on instance variable avoid to need a singleton
>> then it means that it was not a singleton.
>>
>> A singleton is often:
>> you **CANNOT** have two instances at the same time.
>>
>> Many people do not use well singleton so watch out.
>
> We have several variations of singletons in the Pharo codebase, some of
> which do allow multiple instances, some of which don't. But they are
> differentiated by names.
>
> https://www.peteruhnak.com/blog/2015/12/06/singleton-variations/
>
>
> Peter
>
>>
>> Stef
>>
>> On Thu, 19 Jan 2017 11:23:21 +0100, Siemen Baader
>> <[hidden email]> wrote:
>>
>> >Is there a trait to quickly create singletons in Pharo, along the
>> >way of the Ruby Singleton mixin?
>> >
>> >https://ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html
>> >
>> >(and ideally also observer/observable, which I am going to need next..)
>> >
>> >-- Siemen
>>
>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>

--
Using Opera's mail client: http://www.opera.com/mail/