So should i encapsulate the base of my program (the Core if you will) in a class or should i just leave them as private globals?

>as singletons are nothing more than that (globals), yes.. the real module support of D makes it possible to have them more easy than in c++
A Singleton is a class that can be instantiated only once. Nothing else. A
global is a variable that is accessable everywhere. I don't see what these two
definitions have in common.
You could make the instance of the singleton be a global, but you don't have to.

i know that they don't theoretically have much in common. but in real life, all newbies abuse singletons to fit a nice oo-cover around their globals.

In article <bu1bk1$b7n$1@digitaldaemon.com>, Matthias Becker says...
>
>>as singletons are nothing more than that (globals), yes.. the real module support of D makes it possible to have them more easy than in c++
>A Singleton is a class that can be instantiated only once. Nothing else. A
>global is a variable that is accessable everywhere. I don't see what these two
>definitions have in common.
>You could make the instance of the singleton be a global, but you don't have to.
>
>

In article <bu1bk1$b7n$1@digitaldaemon.com>, Matthias Becker says...
>
>>as singletons are nothing more than that (globals), yes.. the real module support of D makes it possible to have them more easy than in c++
>A Singleton is a class that can be instantiated only once. Nothing else. A
>global is a variable that is accessable everywhere. I don't see what these two
>definitions have in common.
>You could make the instance of the singleton be a global, but you don't have to.
>
>

this site

http://home.earthlink.net/~huston2/dp/patterns.html

contains every thing I know about patterns.
check the singleton and why and when should be used.

I prefer to consult that insted of
"Thinking in Patterns" by Bruce Eckel
at http://mindview.net/Books/TIPatterns/

Ant

You should be able to implement a Singleton pattern
easy.
This is what I do in Java

public class One{
     public static One one;

public static void getOne(){
        if(one == null){
              one new One();
            }
    }

private One(){ // private constructor
   //construct stuff
}

}

This way if there is an instance of One already
you cannot make another One.

This was good for me in Java because I found
that when clicking a JTable for some reason the
Thread goes through the event listener method
twice.

The Singleton pattern solved this problem for
me.


Phill.




"imr1984" <imr1984_member@pathlink.com> wrote in message news:bu0da8$1qic$1@digitaldaemon.com...
> Often programmers make classes that are only intended to have one instance
for
> the duration of the whole program. These are called singleton classes. D
should
> have built in support for them so that a singleton object will have its
own
> methods generated for it, without the use of a this pointer. This would
save on
> a this parameter being pushed on stack to a singleton class method.
>
> Walter, what da ya say?
>
>

The best solution is to define a template which creates one instance, when this instance is requested. For example:

template <class T> class Singleton {
    private T *_object;
    T *object() {
        if (_object == null) _object = new T();
        return _object;
    }
}


"Phill" <phill@pacific.net.au> wrote in message news:bu20mp$1ft2$1@digitaldaemon.com...
> You should be able to implement a Singleton pattern
> easy.
> This is what I do in Java
>
> public class One{
>      public static One one;
>
> public static void getOne(){
>         if(one == null){
>               one new One();
>             }
>     }
>
> private One(){ // private constructor
>    //construct stuff
> }
>
> }
>
> This way if there is an instance of One already
> you cannot make another One.
>
> This was good for me in Java because I found
> that when clicking a JTable for some reason the
> Thread goes through the event listener method
> twice.
>
> The Singleton pattern solved this problem for
> me.
>
>
> Phill.
>
>
>
>
> "imr1984" <imr1984_member@pathlink.com> wrote in message news:bu0da8$1qic$1@digitaldaemon.com...
> > Often programmers make classes that are only intended to have one
instance
> for
> > the duration of the whole program. These are called singleton classes. D
> should
> > have built in support for them so that a singleton object will have its
> own
> > methods generated for it, without the use of a this pointer. This would
> save on
> > a this parameter being pushed on stack to a singleton class method.
> >
> > Walter, what da ya say?
> >
> >
>
>

No. That leaves you with all the thread nasties and ordering and dead reference problems.

A valid compromise is to have the singleton notionally initialised during module initialisation - a wonderful boon from D, and not to be wasted - and then to have any expensive state created lazily, in a thread-safe fashion. The state is then reference-counted by the module un/initialisation state, so there are no dead-references.






"Achilleas Margaritis" <axilmar@b-online.gr> wrote in message news:bu21hi$1h9a$1@digitaldaemon.com...
> The best solution is to define a template which creates one instance, when this instance is requested. For example:
>
> template <class T> class Singleton {
>     private T *_object;
>     T *object() {
>         if (_object == null) _object = new T();
>         return _object;
>     }
> }
>
>
> "Phill" <phill@pacific.net.au> wrote in message news:bu20mp$1ft2$1@digitaldaemon.com...
> > You should be able to implement a Singleton pattern
> > easy.
> > This is what I do in Java
> >
> > public class One{
> >      public static One one;
> >
> > public static void getOne(){
> >         if(one == null){
> >               one new One();
> >             }
> >     }
> >
> > private One(){ // private constructor
> >    //construct stuff
> > }
> >
> > }
> >
> > This way if there is an instance of One already
> > you cannot make another One.
> >
> > This was good for me in Java because I found
> > that when clicking a JTable for some reason the
> > Thread goes through the event listener method
> > twice.
> >
> > The Singleton pattern solved this problem for
> > me.
> >
> >
> > Phill.
> >
> >
> >
> >
> > "imr1984" <imr1984_member@pathlink.com> wrote in message news:bu0da8$1qic$1@digitaldaemon.com...
> > > Often programmers make classes that are only intended to have one
> instance
> > for
> > > the duration of the whole program. These are called singleton classes.
D
> > should
> > > have built in support for them so that a singleton object will have
its
> > own
> > > methods generated for it, without the use of a this pointer. This
would
> > save on
> > > a this parameter being pushed on stack to a singleton class method.
> > >
> > > Walter, what da ya say?
> > >
> > >
> >
> >
>
>

>i know that they don't theoretically have much in common. but in real life, all newbies abuse singletons to fit a nice oo-cover around their globals.

That's true, right.

imr1984 wrote:
> So should i encapsulate the base of my program (the Core if you will) in a class
> or should i just leave them as private globals?
> 

If you are not going to reuse this "core" at other places within your hierarchy/project, that is it application specific and not something like a layer or a library, you should rather have private globals.

Make everything the simplest way which works. But think a bit and refractor if you find a need to duplicate the code within the same project. Simply don't be afraid to break the code later on. DBC will save you from evil problems after refractoring And have something like CVS handy to track versions and show diffs.

-eye

Right.  Singletons are a terrible hack that attempts to allow C++ to have a module system, as Turbo Pascal / Delphi had with units and as D does with modules.

Really you don't want to use an instance of a class, you want a static block of data that has "methods" which have private visibility onto the scope, and static ctor and dtor for init at program start and shutdown at program termination, in the reverse order of initialization.  Module interdependency order determines which modules get "constructed" first.  You can make it look like a class if you want, but the fundamental difference is that the module "class" and the only "instance" are the same thing.

Doing the above in C++ requires all manner of nasty kludges, and is rife with problems.  It's a pretty fundamental need, and deserves language support.  But D already got this right, so there's nothing more to do there from what I can see.  Just look up "static constructors" on the D Programming Language website.

Sean

"davepermen" <davepermen_member@pathlink.com> wrote in message news:bu0ef1$1sds$1@digitaldaemon.com...
> singletons are one of the most stupid trend-programming-idioms.
>
> most people just use them because they don't know how to design else..
>
> in D, i'd suggest you bether write a module. this _is_ what a singleton _should_be_.
>
> a.k.a.
>
> mySingleton.d
> --------------
> module mySingleton;
>
> private int data;
>
> void set(int value) {
> data = value;
> }
>
> int get() {
> return data;
> }
> --------------
>
> main.d
> --------------
> import mySingleton; // private import? :D
>
> int main(char[][] args) {
> mySingleton.set(10);
> printf("%i" \n,mySingleton.get());
> }
> --------------
>
> like this
>
> In article <bu0da8$1qic$1@digitaldaemon.com>, imr1984 says...
> >
> >Often programmers make classes that are only intended to have one
instance for
> >the duration of the whole program. These are called singleton classes. D
should
> >have built in support for them so that a singleton object will have its
own
> >methods generated for it, without the use of a this pointer. This would
save on
> >a this parameter being pushed on stack to a singleton class method.
> >
> >Walter, what da ya say?