Re: [Harbour] Singleton Design Pattern in harbour objects
Hi I understand, but before we start implementing something brand new native, which BTW leads quite far away as far I can see it, even my simple proposed method can be used without too much concern, and even it can be used by 3rd party libs to provide such singletons, or whatever we call it. AFAICS it's nothing more than a variable (or function) accessible by all program modules with some value, in this case, it's a single instance class. Yes Victor, I see your point. I insisted on a deeper aproach because I was hoping the discussion would reach issues like singleton inheritance, but now I understand it's not a convenient discussion for now. If anything, Harbour may support single instance classes natively to help this case, and this is probably possible to add without deep changes, but I'm not sure we should add a brand new base variable type/scope/implementation until we know all the benefits which this can give us over already existing methods. Ok. Few of us have proposed solutions, it'd be nice if you could comment on them. Oops! Sorry, I thought I was doing that! Thank you Regards Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
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
Re: [Harbour] Singleton Design Pattern in harbour objects
Hello Mindaugas I do not see a problems here also. In both my and Teo's sample extra class is created but it i not hidden from other users around the world (i.e. MyClass1Real() function is public and visible). It is easy to make this function static and accessible only from same module public funcion (only from MyClass1()). Yes, you are right. This could be implemented using preprocessor and magic word SINGLETON, but I do not thing it's something special to be required to implement as a fundamental class feature. OK. I finally see that although singleton classes are very useful, they are not OOP fundamental and therefore it's not interesting to harbour to implement is as a native OOP feature. If you'll ever look at .ppo file generated from CLASS sentence you'll be surprised that this CLASS something is actually a function, and that method definitions are only a calls to methods like :AddMethod() of some magic class HBClass() and these :AddMethod() are actually a call to __clsAddMsg(). Just see src/rtl/tclass.prg. Yes Mindaugas, I understand that. The former solution model I could find was really close to Teo's aproach, but I implemented it directly in hbclass.ch instead of a separete header. Later I took a deeper path and keept the pointer to the singleton instance in the CLASS c structure (class.h) and marked the structure with a boolean flag to indicate wheather a class is singleton, because I was looking forward to implement also a singleton inheritance mechanism, but it revealed as something beyond my technical reach :) Finally I see that this deeper aproach is not better then the aproach Teo suggested, because there's no official definition (yet) about how should desing patterns interact to OOP fundamentals. Singleton inheritance, for example, is a complicated issue : if class A() is singleton and class B() inherits from A, sould class B be singleton too? Or whatif a third class C() also inherits from A, would the threee of them share the same singleton instance? Its something to be figured out... Now I'm pretty convinced that Teo's aproach is the most appropriate. So, you can be sure: if Teo's preprocessor sample is not enough to make you believe you have a real singleton, be sure that you do not have any real class at all, even if you think so. I believe you understand now what I wanted to mean by a real singleton implementation, don't you? You are a newbie here, so, Harbour is a little cheating on you ;) I think you got me! ;) Thank you all for the help! Beat regards Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
case, it's a single instance class. Yes Victor, I see your point. I insisted on a deeper aproach because I was hoping the discussion would reach issues like singleton inheritance, but now I understand it's not a convenient discussion for now. If anything, Harbour may support single instance classes natively to help this case, and this is probably possible to add without deep changes, but I'm not sure we should add a brand new base variable type/scope/implementation until we know all the benefits which this can give us over already existing methods. Ok. Few of us have proposed solutions, it'd be nice if you could comment on them. Oops! Sorry, I thought I was doing that! Yes, I've seen it, but when I wrote my e-mail this wasn't yet the case. I'm happy for the healthy discussion since. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
Leandro, On xbase++ you can create them this way http://databear.wordpress.com/2009/08/28/xbase-singleton-pattern/ Maybe you can adopt this to harbour. Maurilio. Leandro Damasio wrote: Hi, My name is Leandro Damasio and I have started to follow Harbour Project Main Developer List few days ago. I recently started 2D Informatica with my associate Ted, to develop commercial aplications using [x]Harbour. We used xHarbour + BCC55 + HWGUI for about 3 years, until we read xhb-diff.txt document and decided to try Harbour instead. We are about to realease 2DWGUI, an Object Oriented Harbour API to Win32 GUI, and its going to be a free product but not opensource from start. Our experience with opensource development is minimal, but I believe we could be useful by giving sugestions and/or reporting problems at least. My first try: Does harbour have native support to singleton classes? Its an useful design pattern to declare unique instance objects, so the same instance is reacheable/accessible globally by just calling for the the class name. We implemented Singleton objects in xHarbour, but I'm sure the native implementation should be done better by someone who knows the object machine inside. The Singleton Class usage is like below: code CLASS Aplication SINGLETON DATA Status METHOD Init(aParams) METHOD Run() METHOD End() ENDCLASS Procedure Main (...) Aplication():Init(hb_aParams()) Func2() Aplication():End() Return Static Function Func2() Aplication():Run() Return Aplication():Status /code If it is not implemented yet, do you think its a good idea to implement natively? Thanks Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
A minigui wrapper to qt is done by hbqtcommand a xbase++ wrapper to qt is done by Pritpal in contrib\xhp so a hwgui wrapper will be intresting to try the qt powerfull In future hi hope that we can manage set syntax to cover differences by GUI like designed in vianemo also a wvt wrapper will be intresting set GUISYNTAX to XBP,MINIGUI,FIVEWIN,HWGUI,WVT...VFP 2009/11/24 Fernando Athayde fernando_atha...@yahoo.com.br: why don´t you help a development of hbqt, seems a good api (multiplataform), and you can make include files in a hwgui format Thanks Fernando Athayde -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
Leandro, On xbase++ you can create them this way http://databear.wordpress.com/2009/08/28/xbase-singleton-pattern/ Maybe you can adopt this to harbour. Maurilio. Thank you Maurilio The author suggests to use class var and class methods to implement singleton behaviour in xbase++. In most cases this aproach would work in practice for sure in harbour too, but just as a workaround, because Singleton pattern is about the class instantiation. The aproach suggested to xbase++ would force the programmer to use the CLASS clause repeatedly to every DATA and METHOD declaration, even when he wants for sure unique access to all the members of a class. I believe it would be usefull and simpler if one could just declare a class as Singleton and have always acess to the same object instance when calling the class by name. What do you think? Regards, Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
why don´t you help a development of hbqt, seems a good api (multiplataform), and you can make include files in a hwgui format Hi Fernando Thank you for the invitation! Hbqt seems really very interesting project. Of course I would like to help if I could or when I can, but I have to learn more about how it works first. My current commercial focus and programming background are based on Windows. I just didn't ever hear about QT or wxWidgets until some days ago and I got very glad to know such powerfull crossplataform solutions for harbour as wxHarbour and hbqt. I've been studing both. Now our aplications at 2DInfo are been changed from xHarbour to Harbour and from hwGUI to 2DWGUI and once we finish this work, crossplataform funcionality is going to be the next step and then I hope we will be ready to participate more activelly. Best Regards Leandro Damasio From: Fernando Athayde Sent: Tuesday, November 24, 2009 12:51 PM To: Harbour Project Main Developer List. Subject: Res: [Harbour] Singleton Design Pattern in harbour objects why don´t you help a development of hbqt, seems a good api (multiplataform), and you can make include files in a hwgui format Thanks Fernando Athayde De: Leandro Damasio t...@2dinfo.com.br Para: Harbour Project Main Developer List. harbour@harbour-project.org Enviadas: Terça-feira, 24 de Novembro de 2009 12:26:50 Assunto: [Harbour] Singleton Design Pattern in harbour objects Hi, My name is Leandro Damasio and I have started to follow Harbour Project Main Developer List few days ago. I recently started 2D Informatica with my associate Ted, to develop commercial aplications using [x]Harbour. We used xHarbour + BCC55 + HWGUI for about 3 years, until we read xhb-diff.txt document and decided to try Harbour instead. We are about to realease 2DWGUI, an Object Oriented Harbour API to Win32 GUI, and its going to be a free product but not opensource from start. Our experience with opensource development is minimal, but I believe we could be useful by giving sugestions and/or reporting problems at least. My first try: Does harbour have native support to singleton classes? Its an useful design pattern to declare unique instance objects, so the same instance is reacheable/accessible globally by just calling for the the class name. We implemented Singleton objects in xHarbour, but I'm sure the native implementation should be done better by someone who knows the object machine inside. The Singleton Class usage is like below: code CLASS Aplication SINGLETON DATA Status METHOD Init(aParams) METHOD Run() METHOD End() ENDCLASS Procedure Main (...) Aplication():Init(hb_aParams()) Func2() Aplication():End() Return Static Function Func2() Aplication():Run() Return Aplication():Status /code If it is not implemented yet, do you think its a good idea to implement natively? Thanks Leandro Damasio Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 - Celebridades - Música - Esportes ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
On Nov 24, 2009, at 9:26 AM, Leandro Damasio wrote:
Hi,
My name is Leandro Damasio and I have started to follow Harbour Project Main
Developer List few days ago. I recently started 2D Informatica with my
associate Ted, to develop commercial aplications using [x]Harbour. We used
xHarbour + BCC55 + HWGUI for about 3 years, until we read xhb-diff.txt
document and decided to try Harbour instead.
We are about to realease 2DWGUI, an Object Oriented Harbour API to Win32 GUI,
and its going to be a free product but not opensource from start.
Our experience with opensource development is minimal, but I believe we could
be useful by giving sugestions and/or reporting problems at least.
My first try:
Does harbour have native support to singleton classes? Its an useful design
pattern to declare unique instance objects, so the same instance is
reacheable/accessible globally by just calling for the the class name.
We implemented Singleton objects in xHarbour, but I'm sure the native
implementation should be done better by someone who knows the object machine
inside.
The Singleton Class usage is like below:
code
CLASS Aplication SINGLETON
DATA Status
METHOD Init(aParams)
METHOD Run()
METHOD End()
ENDCLASS
Procedure Main (...)
Aplication():Init(hb_aParams())
Func2()
Aplication():End()
Return
Static Function Func2()
Aplication():Run()
Return Aplication():Status
/code
Hi Leandro,
In wxHarbour I've implemented this in the way that wxWidgets does, in fact you
need to implement the same setup (closely) in wxWidgets for C++ that in
wxHarbour:
In every wxWidget application you need to instance a subclass from the wxApp
class (at least you must do it for GUI apps, console ones doesn't require
wxApp), the wxApp class is used among other things for:
- Start the main application process by calling the ::OnInit() method
- Start the main GUI app message/event loop
- Contain application wide properties and method's.
A typically wxHarbour app, would be:
prg
#include wxharbour.ch
FUNCTION Main()
IMPLEMENT_APP( MyApp():New() )
RETURN NIL
CLASS MyApp FROM wxApp
PRIVATE:
PROTECTED:
PUBLIC:
DATA frame
METHOD OnInit()
PUBLISHED:
ENDCLASS
METHOD FUNCTION OnInit() CLASS MyApp
CREATE FRAME ::frame ;
TITLE Frame1
@ BUTTON ShowTitle ACTION {|| wxMessageBox( wxGetApp():frame:GetTitle() ) }
SHOW WINDOW ::frame FIT CENTRE
RETURN .T.
/prg
The MyApp class is instantiated in the Main function, and it can be
retrieved anywhere in the app by using the wxGetApp() function, so it can be
used in a application wide way.
If it is not implemented yet, do you think its a good idea to implement
natively?
I don't understand what do you mean by natively, if you mean to:
- Limit the number of instances
- automate the instantiation
- calling in the app
I think that it can be done easily by simply using the Harbour's Preprocessor
capabilities.
best regards,
Teo
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
Hello Teo! I don't understand what do you mean by natively, if you mean to: - Limit the number of instances - automate the instantiation - calling in the app By native singleton pattern class implementation I mean to provide that a class could be declared as a singleton class and that this singleton class just instanciates once a single object instance which should be then referenced every time the class would be referenced. By native implementation I also mean the conceptual implementation of a singleton classes in harbour. I'm sure there are lots of ways to get singleton-like behaviour from a class, but the more examples I see on how to get it, more it sounds like a general need and more it seems that native implementation would be usefull to the users (and maybe good to the language too). The sintax and behaviour I propose would work like the example below Regards, Leandro Damasio EXAMPLE: = Case 1) A singleton class: code PRG //---// CLASS MyClass SINGLETON // THIS IS A SINGLETON CLASS!!! DATA Status INIT 0 METHOD ChangeStatus() INLINE ::Status := 1 ENDCLASS *** Procedure Main *** ? MyClass():Status // 0 // first new object is instantiated and kept as the single one ? MyClass():ChangeStatus() // 1 // single object is referred to run :Changestatus() ? MyClass():Status // 1 // single object status has changed Return Case 2) A not singleton class: //---// CLASS MyClass // NOT A SINGLETON CLASS!!! DATA Status INIT 0 METHOD ChangeStatus() INLINE ::status := 1 ENDCLASS *** Procedure Main *** ? MyClass():Status // 0 // first new object was instantiated ? MyClass():ChangeStatus() // 1 // second new object runs :ChangeStatus() ? MyClass():Status // 0 // third new object is instantiated Return /PRG /code ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
This looks like a PUBLIC var initialized with an object from an INIT PROC and protected from additional instances. Brgds, Viktor On 2009 Nov 24, at 21:54, Leandro Damasio wrote: Hello Teo! I don't understand what do you mean by natively, if you mean to: - Limit the number of instances - automate the instantiation - calling in the app By native singleton pattern class implementation I mean to provide that a class could be declared as a singleton class and that this singleton class just instanciates once a single object instance which should be then referenced every time the class would be referenced. By native implementation I also mean the conceptual implementation of a singleton classes in harbour. I'm sure there are lots of ways to get singleton-like behaviour from a class, but the more examples I see on how to get it, more it sounds like a general need and more it seems that native implementation would be usefull to the users (and maybe good to the language too). The sintax and behaviour I propose would work like the example below Regards, Leandro Damasio EXAMPLE: = Case 1) A singleton class: code PRG //---// CLASS MyClass SINGLETON // THIS IS A SINGLETON CLASS!!! DATA Status INIT 0 METHOD ChangeStatus() INLINE ::Status := 1 ENDCLASS *** Procedure Main *** ? MyClass():Status // 0 // first new object is instantiated and kept as the single one ? MyClass():ChangeStatus() // 1 // single object is referred to run :Changestatus() ? MyClass():Status // 1 // single object status has changed Return Case 2) A not singleton class: //---// CLASS MyClass // NOT A SINGLETON CLASS!!! DATA Status INIT 0 METHOD ChangeStatus() INLINE ::status := 1 ENDCLASS *** Procedure Main *** ? MyClass():Status // 0 // first new object was instantiated ? MyClass():ChangeStatus() // 1 // second new object runs :ChangeStatus() ? MyClass():Status // 0 // third new object is instantiated Return /PRG /code ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
On Nov 24, 2009, at 2:54 PM, Leandro Damasio wrote: Hello Teo! I don't understand what do you mean by natively, if you mean to: - Limit the number of instances - automate the instantiation - calling in the app By native singleton pattern class implementation I mean to provide that a class could be declared as a singleton class and that this singleton class just instanciates once a single object instance which should be then referenced every time the class would be referenced. By native implementation I also mean the conceptual implementation of a singleton classes in harbour. I'm sure there are lots of ways to get singleton-like behaviour from a class, but the more examples I see on how to get it, more it sounds like a general need and more it seems that native implementation would be usefull to the users (and maybe good to the language too). The sintax and behaviour I propose would work like the example below Regards, Leandro Damasio EXAMPLE: = Case 1) A singleton class: code PRG //---// CLASS MyClass SINGLETON // THIS IS A SINGLETON CLASS!!! DATA Status INIT 0 METHOD ChangeStatus() INLINE ::Status := 1 ENDCLASS *** Procedure Main *** ? MyClass():Status // 0 // first new object is instantiated and kept as the single one ? MyClass():ChangeStatus() // 1 // single object is referred to run :Changestatus() ? MyClass():Status // 1 // single object status has changed Return Case 2) A not singleton class: //---// CLASS MyClass // NOT A SINGLETON CLASS!!! DATA Status INIT 0 METHOD ChangeStatus() INLINE ::status := 1 ENDCLASS *** Procedure Main *** ? MyClass():Status // 0 // first new object was instantiated ? MyClass():ChangeStatus() // 1 // second new object runs :ChangeStatus() ? MyClass():Status // 0 // third new object is instantiated Return /PRG /code Hello Leandro, I know that you want to integrate it at low level in the Harbour Object engine, but how about the following sample: prg #include hbclass.ch #xcommand SINGLETON CLASS clsName [ FROM fromCls ] = ; FUNCTION clsName() ;; STATIC obj ;; RETURN iif( obj = NIL, obj := S_clsName(), obj ) ;; CLASS S_clsName [ FROM fromCls ] #xcommand SINGLETON METHOD mtdName CLASS clsName = ; METHOD mtdName CLASS S_clsName SINGLETON CLASS MyClass DATA Status INIT 0 METHOD ChangeStatus() INLINE ::Status := 1 METHOD RevertStatus() END CLASS SINGLETON METHOD RevertStatus CLASS MyClass RETURN ::Status := 0 FUNCTION Main() ? MyClass():Status // 0 ? MyClass():ChangeStatus() // 1 ? MyClass():Status // 1 ? MyClass():RevertStatus() // 0 RETURN NIL /prg best regards, Teo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
Viktor Szakáts said: This looks like a PUBLIC var initialized with an object from an INIT PROC and protected from additional instances. Thanks Viktor Sure it could be explicitly implemented as you suggested for some cases, but my intention is to propose a more comprehensive solution. If singleton clause could be hardcoded in the class declaration, a developer could program a singleton class and share it with other users without to care if they know that it has to be instantiated only once or if they know how to assure acess to a unique instance of it - the class would be a singleton class and that would be all. Singleton classes happen in programming because there are singleton objects in real life, so the native concept of singleton classes in harbour would make programming safer, easier and clearer. Regards, Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
Hi, Case 1) A singleton class: code PRG //---// CLASS MyClass SINGLETON // THIS IS A SINGLETON CLASS!!! DATA Status INIT 0 METHOD ChangeStatus() INLINE ::Status := 1 ENDCLASS *** Procedure Main *** ? MyClass():Status // 0 ? MyClass():ChangeStatus() // 1 ? MyClass():Status // 1 Return Case 2) A not singleton class: CLASS MyClass // NOT A SINGLETON CLASS!!! DATA Status INIT 0 METHOD ChangeStatus() INLINE ::status := 1 ENDCLASS ? MyClass():Status // 0 ? MyClass():ChangeStatus() // 1 ? MyClass():Status // 0 Return Since I do not know anything about singletons and doubletons, here is two simple different implementations that came to my mind (and I guess 5 more different approaches can be use to get the expected result): #include hbclass.ch STATIC s_oSingleton1 PROC main() ? MyClass1():Status ? MyClass1():ChangeStatus() ? MyClass1():Status ? MyClass2():Status ? MyClass2():ChangeStatus() ? MyClass2():Status RETURN FUNC MyClass1() IF s_oSingleton1 == NIL s_oSingleton1 := MyClass1Real() ENDIF RETURN s_oSingleton1 CLASS MyClass1Real DATA Status INIT 0 METHOD ChangeStatus() INLINE ::Status := 1 ENDCLASS CLASS MyClass2 CLASSDATA Status INIT 0 METHOD ChangeStatus() INLINE ::Status := 1 ENDCLASS Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
Teo Fonrouge said: I know that you want to integrate it at low level in the Harbour Object engine, but how about the following sample: #xcommand SINGLETON CLASS clsName [ FROM fromCls ] = ; FUNCTION clsName() ;; STATIC obj ;; RETURN iif( obj = NIL, obj := S_clsName(), obj ) ;; CLASS S_clsName [ FROM fromCls ] Hi Teo, Yes this is a smart solution, although it is limited to one singleton class per module, but my intention is to implement a unified solution to singleton classes in shared libraries. My proposal is that it be implemented in such a way that one developer can declare a singleton class, program its composition and behavior, box it in a library and share it to other programmers knowing for sure that nobody will can double instantiate it and cause error, because he declared to the machine that this can't be done. Best regards Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
This looks like a PUBLIC var initialized with an object from an INIT PROC and protected from additional instances. Thanks Viktor Sure it could be explicitly implemented as you suggested for some cases, but my intention is to propose a more comprehensive solution. If singleton clause could be hardcoded in the class declaration, a developer could program a singleton class and share it with other users without to care if they know that it has to be instantiated only once or if they know how to assure acess to a unique instance of it - the class would be a singleton class and that would be all. Singleton classes happen in programming because there are singleton objects in real life, so the native concept of singleton classes in harbour would make programming safer, easier and clearer. I understand, but before we start implementing something brand new native, which BTW leads quite far away as far I can see it, even my simple proposed method can be used without too much concern, and even it can be used by 3rd party libs to provide such singletons, or whatever we call it. AFAICS it's nothing more than a variable (or function) accessible by all program modules with some value, in this case, it's a single instance class. If anything, Harbour may support single instance classes natively to help this case, and this is probably possible to add without deep changes, but I'm not sure we should add a brand new base variable type/scope/implementation until we know all the benefits which this can give us over already existing methods. Few of us have proposed solutions, it'd be nice if you could comment on them. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
Mindaugas Kavaliauskas said: Since I do not know anything about singletons and doubletons, here is two simple different implementations that came to my mind (and I guess 5 more different approaches can be use to get the expected result): Hello Mindaugas, Please forgive me , I wasn't comprehensive enough in my examples and let the wrong idea that I din't know how to simulate singleton-like behavior of a class. I'm a newbie here, please be patient. :) My proposition is that singleton class support for harbour be implemented in such a way that one programmer can declare a singleton class, box it in a library and share it to other harbour users around the world, knowing for sure that nobody could instantiate it more than once per execution (even by mistake) and that there should be no need to provide any exceptional instructions, formalities, tips or tricks with the library to assure that the user will always acess the same unique instance of the class during all the execution of the program, because the class was declared as a singleton class and the machine would know how to deal with it, even if the user doesn't even know what does singleton means. Regards Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
On Tue, 24 Nov 2009, Leandro Damasio wrote:
Hi,
I know that you want to integrate it at low level in the Harbour Object
engine, but how about the following sample:
#xcommand SINGLETON CLASS clsName [ FROM fromCls ] = ;
FUNCTION clsName() ;;
STATIC obj ;;
RETURN iif( obj = NIL, obj := S_clsName(), obj ) ;;
CLASS S_clsName [ FROM fromCls ]
Hi Teo,
Yes this is a smart solution, although it is limited to one singleton
class per module, but my intention is to implement a unified solution
to singleton classes in shared libraries.
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.
My proposal is that it be implemented in such a way that one developer
can declare a singleton class, program its composition and behavior,
box it in a library and share it to other programmers knowing for sure
that nobody will can double instantiate it and cause error, because he
declared to the machine that this can't be done.
So the above #xcommand is sth what you are looking for.
It passes all conditions you've defined so far.
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.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Singleton Design Pattern in harbour objects
Hi, Leandro Damasio wrote: My proposition is that singleton class support for harbour be implemented in such a way that one programmer can declare a singleton class, box it in a library and share it to other harbour users around the world, knowing for sure that nobody could instantiate it more than once per execution (even by mistake) and that there should be no need to provide any exceptional instructions, formalities, tips or tricks with the library to assure that the user will always acess the same unique instance of the class during all the execution of the program, because the class was declared as a singleton class and the machine would know how to deal with it, even if the user doesn't even know what does singleton means. I do not see a problems here also. In both my and Teo's sample extra class is created but it i not hidden from other users around the world (i.e. MyClass1Real() function is public and visible). It is easy to make this function static and accessible only from same module public funcion (only from MyClass1()). This could be implemented using preprocessor and magic word SINGLETON, but I do not thing it's something special to be required to implement as a fundamental class feature. If you'll ever look at .ppo file generated from CLASS sentence you'll be surprised that this CLASS something is actually a function, and that method definitions are only a calls to methods like :AddMethod() of some magic class HBClass() and these :AddMethod() are actually a call to __clsAddMsg(). Just see src/rtl/tclass.prg. So, you can be sure: if Teo's preprocessor sample is not enough to make you believe you have a real singleton, be sure that you do not have any real class at all, even if you think so. You are a newbie here, so, Harbour is a little cheating on you ;) Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
