Re: [fpc-pascal] UML state machine drawing tool
Am Freitag, den 08.12.2006, 21:40 +0100 schrieb Michael Van Canneyt: > > On Fri, 8 Dec 2006, Marc Santhoff wrote: > > > Hi, > > > > is anyone aware of a UML tool capable of making class diagrams and state > > diagrams and emitting fpc compilable pascal code (or at least being > > configurable to do so)? > > I think Umbrello (part of KDE) can do this. It can save everything as XML, Looks good, I'll check it. > I guess you could parse that and emit pascal. (or ask the developers to > add a pascal output module, which would be even better...) Yes, that's the problem with most of the tools, object pascal support has to be done first. Thanks, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] UML state machine drawing tool
Am Freitag, den 08.12.2006, 19:05 -0200 schrieb Felipe Monteiro de Carvalho: > On 12/8/06, Marc Santhoff <[EMAIL PROTECTED]> wrote: > > is anyone aware of a UML tool capable of making class diagrams and state > > diagrams and emitting fpc compilable pascal code (or at least being > > configurable to do so)? > > I did a quick search and found this: > > http://www.modelmakertools.com/modelmaker/index.html > > It supports Object Pascal. You can download a Demo to test. Interesting, looks if that is the company (or at least their product) formerly known as "White Ants". I thought they have been bought by Borland ... Thanks, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] GetEpochTime not found
Hi, I've got some funny problem here. The program compiled well with fpc up to version 1.9.4. I haven't touched it for a while and now it fails with fpc 2.0.2. The source snippet in queston is: function TStorable.generateID: integer; begin //writeln(GetEpochTime); does not work anymore result := sysutils.GetEpochTime(); // does not work either //result := fpTime; // this works! end; As you can see I've tried prefixing with the correct unit specifier but it fails: CommonTypes.pp(207,21) Error: Identifier not found "GetEpochTime" Checking the source and even grep'ping and strings'ing sysutils.ppu and sysutils.o the function GetEpochTime is there: $ grep GetEpochTime /home/marc/fpc-2.0.2/lib/fpc/2.0.2/units/i386-freebsd/rtl/sysutils.ppu Binary file /home/marc/fpc-2.0.2/lib/fpc/2.0.2/units/i386-freebsd/rtl/sysutils.ppu matches But the compiler doesn't find it: from fpc ... -vt ... PPU Loading /home/marc/fpc-2.0.2/lib/fpc/2.0.2/units/i386-freebsd/rtl/sysutils.ppu ... I'm stuck, what is missing here or how can I go on debugging the problem? TIA, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
>> Try this. >> http://bdn.borland.com/article/22576 NewInstance/FreeInstance is what I would have recommended as well. > Maybe we should include an implementation in FPC by default ? How ? The article works as-is AFAIK. Btw, I think singletons are nonsense too. Why is a global variable evil, and a singleton class not ? You are right, beware of singletons. Being a simple pattern to implement it's often misused and sometimes creates more problems than it solves, it's a global variable after all, and you should put an extra effort to try to avoid it as you would avoid a global variable. It was one of the things I've learnt through unit testing, using a singleton breaks the independency between tests, because the singleton carries state with it that lasts as long as the program runs. In this case thinking about how to make tests independent of each other and trying to introduce a mock object for the singleton, you can get rid of it in a lot of cases. The best thing is usually to think about how we can substitute a singleton in the client class with a parameter in the constructor of the client class. See this article for further explanation: http://www-128.ibm.com/developerworks/library/co-single.html Regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] UML state machine drawing tool
On 12/8/06, Marc Santhoff <[EMAIL PROTECTED]> wrote: is anyone aware of a UML tool capable of making class diagrams and state diagrams and emitting fpc compilable pascal code (or at least being configurable to do so)? I did a quick search and found this: http://www.modelmakertools.com/modelmaker/index.html It supports Object Pascal. You can download a Demo to test. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] UML state machine drawing tool
On Fri, 8 Dec 2006, Marc Santhoff wrote: > Hi, > > is anyone aware of a UML tool capable of making class diagrams and state > diagrams and emitting fpc compilable pascal code (or at least being > configurable to do so)? I think Umbrello (part of KDE) can do this. It can save everything as XML, I guess you could parse that and emit pascal. (or ask the developers to add a pascal output module, which would be even better...) Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Daniël Mantione wrote: > > Op Fri, 8 Dec 2006, schreef Micha Nelissen: > >> Btw, I think singletons are nonsense too. Why is a global variable evil, >> and a singleton class not ? > > Well, a singleton can hide and/or protect its private data. Not more than a global variable of the same class type ? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] UML state machine drawing tool
Hi, is anyone aware of a UML tool capable of making class diagrams and state diagrams and emitting fpc compilable pascal code (or at least being configurable to do so)? TIA, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Op Fri, 8 Dec 2006, schreef Micha Nelissen: > Btw, I think singletons are nonsense too. Why is a global variable evil, > and a singleton class not ? Well, a singleton can hide and/or protect its private data. Actually, a unit is a singleton. The procedures are the methodes, the interface declares the public methode and the implementation the private methods. The constructor is the initialization section and the destructor the finalization section. But, in pure OOP the unit concept does not exist. I interpret the singleton as the OOP equivalent of the unit. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Michael Van Canneyt wrote: >> Try this. >> http://bdn.borland.com/article/22576 NewInstance/FreeInstance is what I would have recommended as well. > Maybe we should include an implementation in FPC by default ? How ? The article works as-is AFAIK. Btw, I think singletons are nonsense too. Why is a global variable evil, and a singleton class not ? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] RE: [lazarus] Article on Pixel.
On Fri, 8 Dec 2006, George Birbilis wrote: > > The latest issue of Linux Journal features an article about > > Pixel (By Pavel Kanzelsberger). > > It gives it a very good comment. Pity it's not mentioned that > > it's written using FPC. > > (the article is written by a writer/publisher, not a programmer). > > > > For the Lazarus users: Pixel is written using a widget-set > > developed by Pavel. > > Greetings, > Is it online? The article ? Not that I know of. The program is: http://www.kanzelsberger.com/ Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Am Freitag, den 08.12.2006, 10:50 +0200 schrieb Graeme Geldenhuys: > Bottom line: How can we hide the constructor of a class? As far as I > can see you cannot decrease the visibility of a method compared to > it's inherited class. Why shouldn't we be allowed to? C++, C# does! > > I found this by trying to implement a True Singleton in Free Pascal / > Delphi. For those that don't know, a Singleton is a Design Pattern > that allows only one instance of a class. It seems it is impossible > to do in Free Pascal / Delphi. :-( > > See attached code for a demonstration of the problem. One working solution is to use a global var. This is bad but acceptable for a singleton imo. If would be nice if the variable could be hidden. Smth like this: ... var _mySingleton: TSingleton; constructor TSingleton.create; begin if not(assigned(_mySingleton)) then begin inherited; ... do initializations ... _mySingleton := self; end; end; initilization _mySingleton := NIL; end. HTH, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Good revision on wince cross-compiler
On 12/8/06, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: Does anyone know a good revision that works with Lazarus-WinCE? A few weeks ago I experimented and found out that fpc 5389 and Lazarus 10204 worked for me on arm-wince. I'm sticking to these revisions for the time being, making my local modifications as needed. However, my Lazarus projects are probably not typical. I only have a few very basic LCL-based windowed applications for testing and the main work consists of DLLs exposing ported Delphi code to a .NET CF host application. HTH TOndrej ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Good revision on wince cross-compiler
Hi, 5191 works very well for me. Gabor ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Good revision on wince cross-compiler
Hello, I was testing fpc revisions for wince, based on the page: http://www.freepascal.org/wiki/index.php/Tested_Unstable_Revisions I first tryed 5431, but it doesn´t compile correctly. Next I tryed 5370. Everything compiles fine, but when I tested a hello world lazarus application it runs, but shows no output (doesn´t create the window). And that app was working perfectly with some very old revisions. Does anyone know a good revision that works with Lazarus-WinCE? thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Graeme Geldenhuys wrote: On 12/8/06, TOndrej <[EMAIL PROTECTED]> wrote: On 12/8/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > I still don't know why we can't decrease visibility in Free Pascal. > Is there some internal language design that prevents it? A class definition (or at least its parts visible from outside) can be understood as a kind of contract. If you have a class TDog with a public property Tail then, by definition, any TDog descendant I understand your example and that makes sense, but would be handy in certain cases to change it. A TBoxer could be considered a TDog without a tail :) I'm not even sure if there is a language which allows demoting visibility of inherited class members. It would seem odd to me. Just my 2c, of course. ;-) C++, C#, VB.Net are three I know of. I think Java also allows it. Yes, but that causes other problems. I worked for a time for a company that wrote programs for aeronautical equipment. In these cases the above mentioned languages could not be used. C was ok, and C++ could only be used if you followed very strict rules (and a lint program to guarantee you were following the rules). Pascal however had far fewer restrictions (almost none if I remember correctly). Modula-2 could be freely used. If we relax the Pascal rules we will end up with a non-secure language like the above. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On Fri, 8 Dec 2006, Steve Williams wrote: > > I found this by trying to implement a True Singleton in Free Pascal / > > Delphi. For those that don't know, a Singleton is a Design Pattern > > that allows only one instance of a class. It seems it is impossible > > to do in Free Pascal / Delphi. :-( > > Try this. > http://bdn.borland.com/article/22576 Maybe we should include an implementation in FPC by default ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease thevisibility of a method?
> On 8 dec 2006, at 10:55, Graeme Geldenhuys wrote: > > > I still don't know why we can't decrease visibility in Free Pascal. > > Is there some internal language design that prevents it? > > At least Borland explicitly says you cannot do that: >http://info.borland.com/techpubs/delphi/delphi5/oplg/classes.html Delphi 5 onwards generates a hint for each method that is of a lower visibility thatn its ancestors implementation. I've used the following to implement a singleton before: unit x; interface type ISingleton = interface [-GUID GOES HERE-] procedure SingletonAction; end; var MySingleton: ISingleton; implementation type TSingleton = class(TInterfacedObject, ISingleton) private procedure SingletonAction; end; procedure TSingleton .SingletonAction; begin [] end; initialization MySingleton := TSingleton.Create; finalization MySingleton := nil; end. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
> I found this by trying to implement a True Singleton in Free Pascal / > Delphi. For those that don't know, a Singleton is a Design Pattern > that allows only one instance of a class. It seems it is impossible > to do in Free Pascal / Delphi. :-( Try this. http://bdn.borland.com/article/22576 -- Sly This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Article on Pixel.
Hi, The latest issue of Linux Journal features an article about Pixel (By Pavel Kanzelsberger). It gives it a very good comment. Pity it's not mentioned that it's written using FPC. (the article is written by a writer/publisher, not a programmer). For the Lazarus users: Pixel is written using a widget-set developed by Pavel. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
> I'm not even sure if there is a language which allows demoting > visibility of inherited class members. It would seem odd to me. Just > my 2c, of course. ;-) C++, C#, VB.Net are three I know of. I think Java also allows it. In these languages, AFAIK, it's allowed, the compiler generates a warning, but the visibility does not actually change. You would still be able to access the member, if not directly on a variable of the descendant type then certainly by typecasting to the ancestor type. HTH TOndrej ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On 8 dec 2006, at 14:03, Graeme Geldenhuys wrote: There is a lot of things in life we shouldn't do, but we do. :-) At least give us the choice, maybe via a compiler directive and keep the compiler warning in place. That way we can use it responsibly when required, This is a generic argument which you can use in support of pretty much any relaxing of semantic/syntax rules. as in the case of implementing a true singleton. I'm sure there are more examples. As it stands currently (my sample singleton code) the developer can still screw up by creating a new instance instead of going through the global function. This particular issue is caused by the fact that in Delphi-style Object Pascal classes automatically inherit from TObject, which has a public constructor. And if you override the constructor with your own, they no longer can do that either (although it's obviously a run time and not compile time check). One thing that could be changed is the compile so that you get a compile-time error if you try type tc = class constructor create; virtual; abstract; end; var c: tc; begin c := tc.create end. (currently this compiles with only a warning about the fact that tc has abstract methods) It would however still only give a run time error if you'd instead do type tc = class constructor create; virtual; abstract; end; ttc = class of tc; var cc: ttc; c: tc; begin cc := tc; c := cc.create; end. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Graeme Geldenhuys schreef: On 12/8/06, Jonas Maebe <[EMAIL PROTECTED]> wrote: Quote: "You should not change the access modifier for inherited members." So it's possible but discouraged, and they give warnings (and sometimes errors) for it with the recommendation "Do not exclude a warning from this rule." There is a lot of things in life we shouldn't do, but we do. :-) At least give us the choice, maybe via a compiler directive and keep the compiler warning in place. That way we can use it responsibly when required, as in the case of implementing a true singleton. I'm sure there are more examples. As it stands currently (my sample singleton code) the developer can still screw up by creating a new instance instead of going through the global function. I think it cannot be prevented. Suppose you could hide the constructor and TSingleton.Create was not visible, I still could create a TSingleton object and call the TObject.Create on it. var Singleton1, Singleton2: TSingleton; begin Singleton1 := TSingleton.CreateInstance; TObject(Singleton1).Create; Singleton2 := TSingleton.CreateInstance; TObject(Singleton).Create; // now there are two Singleton objects. end. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On 12/8/06, Jonas Maebe <[EMAIL PROTECTED]> wrote: Quote: "You should not change the access modifier for inherited members." So it's possible but discouraged, and they give warnings (and sometimes errors) for it with the recommendation "Do not exclude a warning from this rule." There is a lot of things in life we shouldn't do, but we do. :-) At least give us the choice, maybe via a compiler directive and keep the compiler warning in place. That way we can use it responsibly when required, as in the case of implementing a true singleton. I'm sure there are more examples. As it stands currently (my sample singleton code) the developer can still screw up by creating a new instance instead of going through the global function. -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On 8 dec 2006, at 13:44, Graeme Geldenhuys wrote: I'm not even sure if there is a language which allows demoting visibility of inherited class members. It would seem odd to me. Just my 2c, of course. ;-) C++, C#, VB.Net are three I know of. http://msdn2.microsoft.com/en-us/library/ms182332(VS.80).aspx Quote: "You should not change the access modifier for inherited members." So it's possible but discouraged, and they give warnings (and sometimes errors) for it with the recommendation "Do not exclude a warning from this rule." As far as I understand the text on that page, the only case where it's considered "safe" is if the the method/class is declared "final". We do not have final methods/classes in Object Pascal, and such final methods/classes are often considered a cause of problems in themselves (because you can bet sooner or latter someone will have some need to override/inherit anyway). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On 12/8/06, TOndrej <[EMAIL PROTECTED]> wrote: On 12/8/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > I still don't know why we can't decrease visibility in Free Pascal. > Is there some internal language design that prevents it? A class definition (or at least its parts visible from outside) can be understood as a kind of contract. If you have a class TDog with a public property Tail then, by definition, any TDog descendant I understand your example and that makes sense, but would be handy in certain cases to change it. I'm not even sure if there is a language which allows demoting visibility of inherited class members. It would seem odd to me. Just my 2c, of course. ;-) C++, C#, VB.Net are three I know of. I think Java also allows it. -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On 12/8/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: I still don't know why we can't decrease visibility in Free Pascal. Is there some internal language design that prevents it? A class definition (or at least its parts visible from outside) can be understood as a kind of contract. If you have a class TDog with a public property Tail then, by definition, any TDog descendant (TBulldog, TLabrador, TDingo etc.) must have the public property Tail. Otherwise they wouldn't be TDog but something else, again by definition. I'm not even sure if there is a language which allows demoting visibility of inherited class members. It would seem odd to me. Just my 2c, of course. ;-) HTH TOndrej ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On 8 dec 2006, at 10:55, Graeme Geldenhuys wrote: I still don't know why we can't decrease visibility in Free Pascal. Is there some internal language design that prevents it? At least Borland explicitly says you cannot do that: http://info.borland.com/techpubs/delphi/delphi5/oplg/classes.html "You can increase the visibility of a member in a descendant class by redeclaring it, but you cannot decrease its visibility. For example, a protected property can be made public in a descendant, but not private. Moreover, published members cannot become public in a descendant class." Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On 12/8/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: I think the solution is to create a public constructor which throws an NotImplemented exception or something like that. Ok, that works, or at least stops a developer from trying to create a instance directly. In the exception message, I mention the correct function they should have used. Note: instead of making function GetSingleton : TSingleton; a global function you could make it class function GetInstance too. Yes I know, thanks. But I prefer to use the function, as it is less typing, especially when the class name is lengthy. I also normally prefix it with a 'g' to show it is a global singleton function. gLog vs TLogToFile.GetSingleton When you use singletons a lot (as I do), less typing is better. :) PS: I still don't know why we can't decrease visibility in Free Pascal. Is there some internal language design that prevents it? -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Graeme Geldenhuys schreef: On 12/8/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: Maybe I am analyzing your output wrong, but to me it seems as if the contructor of TObject is called in the third case. printdata seems to print an empty text. So the protected contructor is unreachable, but the public constructor in TObject remains public. That's correct, which is even worse. It gives us a half-baked object. fData is never initialized. Putting a writeln() statement inside TSingleton.Create shows that on the 3rd instance it is never executed. I think the solution is to create a public constructor which throws an NotImplemented exception or something like that. Then you create a protected (or private) constructor constructor CreateSingletonInstance; which is accessible only in that unit. Note: instead of making function GetSingleton : TSingleton; a global function you could make it class function GetInstance too. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
On 12/8/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: Maybe I am analyzing your output wrong, but to me it seems as if the contructor of TObject is called in the third case. printdata seems to print an empty text. So the protected contructor is unreachable, but the public constructor in TObject remains public. That's correct, which is even worse. It gives us a half-baked object. fData is never initialized. Putting a writeln() statement inside TSingleton.Create shows that on the 3rd instance it is never executed. [graemeg-linux] singleton > ./singtest Tsingleton.Create PrintData hello world - Tsingleton.Create PrintData hello world hello world 2 - PrintData -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Graeme Geldenhuys schreef: Bottom line: How can we hide the constructor of a class? As far as I can see you cannot decrease the visibility of a method compared to it's inherited class. Why shouldn't we be allowed to? C++, C# does! I found this by trying to implement a True Singleton in Free Pascal / Delphi. For those that don't know, a Singleton is a Design Pattern that allows only one instance of a class. It seems it is impossible to do in Free Pascal / Delphi. :-( See attached code for a demonstration of the problem. And here is the output. The first two '>> PrintData' sections are correct and use the singleton as it should be used. The third '>> PrintData' section is by declaring a new variable of TSingleton and creating it. The problem is even though the constructor is declared in the protected section, Free Pascal just gives a compiler warning and it stays public. What is the reason why we may not decrease visibility of methods or properties? Couldn't we add this feature to Free Pascal? Or at least in the ObjFPC mode! Maybe I am analyzing your output wrong, but to me it seems as if the contructor of TObject is called in the third case. printdata seems to print an empty text. So the protected contructor is unreachable, but the public constructor in TObject remains public. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
Bottom line: How can we hide the constructor of a class? As far as I
can see you cannot decrease the visibility of a method compared to
it's inherited class. Why shouldn't we be allowed to? C++, C# does!
I found this by trying to implement a True Singleton in Free Pascal /
Delphi. For those that don't know, a Singleton is a Design Pattern
that allows only one instance of a class. It seems it is impossible
to do in Free Pascal / Delphi. :-(
See attached code for a demonstration of the problem.
And here is the output. The first two '>> PrintData' sections are
correct and use the singleton as it should be used. The third '>>
PrintData' section is by declaring a new variable of TSingleton and
creating it.
The problem is even though the constructor is declared in the
protected section, Free Pascal just gives a compiler warning and it
stays public. What is the reason why we may not decrease visibility
of methods or properties? Couldn't we add this feature to Free
Pascal? Or at least in the ObjFPC mode!
Is there another way of implementing a true singleton in Free Pascal,
maybe using some other language construct.
--- START Output ---
[graemeg-linux] singleton > ./singtest
PrintData
hello world
-
PrintData
hello world
hello world 2
-
PrintData
--- END Output ---
--
Graeme Geldenhuys
There's no place like S34° 03.168' E018° 49.342'
unit sing; //first singleton
{$mode objfpc}{$H+}
interface
type
TSingleton = class
private
fData : string;
protected
constructor Create;
public
procedure PrintData; virtual;
end;
function GetSingleton : TSingleton;
implementation
var
asing : TSingleton = nil;
function GetSingleton : TSingleton;
begin
if asing = nil then
asing := TSingleton.Create;
Result := asing;
end;
constructor TSingleton.Create;
begin
inherited;
fData := 'hello world';
end;
procedure TSingleton.PrintData;
begin
writeln('>> PrintData');
Writeln(fData);
end;
end.
unit sing2; //second singleton
{$mode objfpc}{$H+}
interface
uses
sing;
type
TSingleton2 = class(TSingleton)
private
fData2 : string;
protected
constructor Create;
public
procedure PrintData; override;
end;
function GetSingleton2 : TSingleton2;
implementation
var
asing2 : TSingleton2 = nil;
function GetSingleton2 : TSingleton2;
begin
if asing2 = nil then
asing2 := TSingleton2.Create;
Result := asing2;
end;
constructor TSingleton2.Create;
begin
inherited;
fData2 := 'hello world 2';
end;
procedure TSingleton2.PrintData;
begin
inherited;
Writeln(fData2);
end;
end.
program singtest; //test program
{$mode objfpc}{$H+}
uses
sing, sing2;
var
c : char;
s: TSingleton;
begin
GetSingleton.PrintData;
WriteLn('-');
GetSingleton2.PrintData;
WriteLn('-');
s := TSingleton.Create;
s.PrintData;
s.Free;
ReadLn(c);
GetSingleton.Free;
GetSingleton2.Free;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] charset conversion
Lot of thanks to alll for your answers ! I'll now try to make best use of them. Dominique. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
