Hi

I do not see any reason for such limitation.
The above #xcommand is universal rule you can define once in some global
.ch file and then you can use it as many times as you want in one or many
modules. I would only modify it a little bit adding protection against
1-st concurrent call in MT environment and making real class function
static so it will not be accessible from external code.

  #xcommand SINGLETON CLASS <!clsName!> ;
            [ FROM <!fromCls1!> [,<!fromClsN!>] ] => ;
     FUNCTION <clsName>() ;;
        STATIC obj, once ;;
        IF obj == NIL ;;
           hb_threadOnce( @once, {|| obj := __S_<clsName>() } ) ;;
        END ;;
     RETURN obj;;
     CLASS <clsName> [ FROM <fromCls1> ] [, <fromClsN> ] STATIC ;
           FUNCTION __S_<clsName>

It can be extended yet but I do not want to make it less readable using
some more complicated PP rules.
So the above #xcommand is sth what you are looking for.
It passes all conditions you've defined so far.

You are right Przemek. I finally see how strong and appropriate this aproach is for harbour users today.

Anyhow really important parts of such feature are not defined at all
and it's not trivial to create such definition and then implement it
keeping basic OOP rules so I would expect that users may want to adopt
this command for his own needs.

I see. I understand Singleton is not a OOP fundamental, but a design pattern. The fundamentals came first - the usage patterns just come later of course, even if after some time, they end becoming fundamentals too.

I had hope that once singleton-like situations hapens to everyone sometime we could define what is not defined yet about singleton classes implementation and implement it to the deepest levels, like singleton inheritance for example.

I'll adopt your version of Teo's suggestion, because it is more economic and so effective as using the CLASS c structure [in class.h] to keep the PHB_ITEM of the singleton object instance.

Thanks for the help!

Regards,
Leandro Damasio
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to