Re: [fpc-pascal] Compiler Warning: Constructor should be public
Graeme Geldenhuys : > A very quick and dirty solution would be to reimplement the public > Create() constructor and immediately raise an exception inside it, > explaining the problem. That way if any developer tries to use that > default constructor, they will get an error - instead of some silent > side-effect later on. Then implement a new public custom constructor > with your desired code. Why "public" then? Perhaps I don't *want* the user to create instances of this class in an uncontrolled way? Vinzent. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler Warning: Constructor should be public
Of course you can't hide methods previously exposed in an inherited
class. But this applies to every member type (fields, properties,
methods), not just constructors. The point of a constructor is not to
new up a class (NewInstance does that), but to execute a block of code
(with checks) before that new instance is returned. By allowing
developers to hide some constructors (private constructor
CreateFromLine for example), other developers are denied the access to
that block of code.
On Wed, Nov 11, 2009 at 2:22 AM, Graeme Geldenhuys
wrote:
> Flávio Etrusco wrote:
>>
>> Graeme, I guess the OP didn't want to reintroduce the 'Create'
>> constructor with lower visibility, just implement a second constructor
>> with private visiblity.
>> It can be useful when implementing singletons and factories to avoid
>> some types of misuse by an unattentive coworker...
>
> The problem is that a constructor (in this case Create) in still always
> public. So that unattentive coworker can very easily use the default
> "public" Create() constructor and by-pass all your custom code in your
> "private" constructor.
>
> So that pretty much makes your custom private constructor useless. Plus
> if the class was instantiated with the default public Create(), there
> could be many other side-effects due to the fact that it by-passed your
> custom code.
>
> And yes I know, such a feature would be very handy for Singleton
> implementations, but alternative solutions are possible. The same could
> be applied to the original poster's code, without creating private or
> protected constructors.
>
> A very quick and dirty solution would be to reimplement the public
> Create() constructor and immediately raise an exception inside it,
> explaining the problem. That way if any developer tries to use that
> default constructor, they will get an error - instead of some silent
> side-effect later on. Then implement a new public custom constructor
> with your desired code.
>
> eg:
>
> TMyClass = class(TObject)
> public
> constructor Create;
> constructor CreateCustom(param1: string);
> end;
>
> ...
>
> constructor TMyClass.Create;
> begin
> raise Exception.Create('Please use CreateCustom instead');
> end;
>
> constructor TMyClass.CreateCustom(param1: string);
> begin
> inherited Create; // <- note inherited call to bypass Exception
> FValue := param1;
>
> end;
>
>
> No private or protected constructors are used and you are guiding the
> developer to only use the CreatCustom constructor, ensuring your custom
> code is executed.
>
> NOTE:
> This is still not a perfect solution, but minimized the potential problems.
>
>
>> IIRC the last time this issue was raised you were on the side for
>> removing the warning - my opinion too ;-)
>
> Maybe I learnt from my mistakes. ;-)
>
>
> Regards,
> - Graeme -
>
> --
> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
> http://opensoft.homeip.net/fpgui/
>
> ___
> fpc-pascal maillist - fpc-pas...@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler Warning: Constructor should be public
On Wednesday 11 November 2009 09:22:30 Graeme Geldenhuys wrote:
> Flávio Etrusco wrote:
> > Graeme, I guess the OP didn't want to reintroduce the 'Create'
> > constructor with lower visibility, just implement a second constructor
> > with private visiblity.
> > It can be useful when implementing singletons and factories to avoid
> > some types of misuse by an unattentive coworker...
>
> The problem is that a constructor (in this case Create) in still always
> public. So that unattentive coworker can very easily use the default
> "public" Create() constructor and by-pass all your custom code in your
> "private" constructor.
Just a thought:
In FP, as with Delphi, TObject is the ultimate ancestor. Would it be possible
to add a modified version of TObject to the RTL where a default constructor
is not defined?
I know that TObject has a lot of functionality but would it be possible for a
user-defined class to be defined without having to inherit from anything? A
sort of user-defined TObject?
:=Nino
>
> So that pretty much makes your custom private constructor useless. Plus
> if the class was instantiated with the default public Create(), there
> could be many other side-effects due to the fact that it by-passed your
> custom code.
>
> And yes I know, such a feature would be very handy for Singleton
> implementations, but alternative solutions are possible. The same could
> be applied to the original poster's code, without creating private or
> protected constructors.
>
> A very quick and dirty solution would be to reimplement the public
> Create() constructor and immediately raise an exception inside it,
> explaining the problem. That way if any developer tries to use that
> default constructor, they will get an error - instead of some silent
> side-effect later on. Then implement a new public custom constructor
> with your desired code.
>
> eg:
>
> TMyClass = class(TObject)
> public
> constructor Create;
> constructor CreateCustom(param1: string);
> end;
>
> ...
>
> constructor TMyClass.Create;
> begin
> raise Exception.Create('Please use CreateCustom instead');
> end;
>
> constructor TMyClass.CreateCustom(param1: string);
> begin
> inherited Create; // <- note inherited call to bypass Exception
> FValue := param1;
>
> end;
>
>
> No private or protected constructors are used and you are guiding the
> developer to only use the CreatCustom constructor, ensuring your custom
> code is executed.
>
> NOTE:
> This is still not a perfect solution, but minimized the potential problems.
>
> > IIRC the last time this issue was raised you were on the side for
> > removing the warning - my opinion too ;-)
>
> Maybe I learnt from my mistakes. ;-)
>
>
> Regards,
> - Graeme -
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] Any Way to catch endless loop in fpc in Wince?
Hello FPC-Pascal, Wednesday, November 11, 2009, 10:34:09 AM, you wrote: JM> It is not possible to know whether a loop is endless or not (at least JM> not in the general case, see the "halting problem"). If you simply JM> want to know whether your application has run its main loop within the JM> last x seconds, you can use a global variable and an extra thread: JM> * set the variable to 1 in the thread and sleep x seconds (note that JM> you have to do this with interlockedexchange, otherwise you can get JM> memory synchronisation issues) JM> * set it to 0 whenever you execute the main application loop (idem) JM> * if it's still 1 when the thread wakes up then the main application JM> loop has not run for x seconds JM> If you have multiple threads in your program, you will need multiple JM> global variables. Or maybe using the same system as Windows, post a custom message to the application and the handler of that message notify the watchdog thread with an acknowledge procedure. If acknowledge takes more than "X" seconds them the "hang" in endless loop is quite sure. Or maybe in the "OnIdle" event of the application ? -- Best regards, JoshyFun ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Any Way to catch endless loop in fpc in Wince?
On 11 Nov 2009, at 00:55, epergola wrote: Is there a way (or a 3rd party component or a library) to catch an endless loop after x seconds in applications running on arm Wince? It is not possible to know whether a loop is endless or not (at least not in the general case, see the "halting problem"). If you simply want to know whether your application has run its main loop within the last x seconds, you can use a global variable and an extra thread: * set the variable to 1 in the thread and sleep x seconds (note that you have to do this with interlockedexchange, otherwise you can get memory synchronisation issues) * set it to 0 whenever you execute the main application loop (idem) * if it's still 1 when the thread wakes up then the main application loop has not run for x seconds If you have multiple threads in your program, you will need multiple global variables. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Any Way to catch endless loop in fpc in Wince?
I mean at runtime, where the app is deployed, not in the Lazarus IDE debugger. -- View this message in context: http://old.nabble.com/Any-Way-to-catch-endless-loop-in-fpc-in-Wince--tp26293620p26297681.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler Warning: Constructor should be public
Flávio Etrusco wrote:
>
> Graeme, I guess the OP didn't want to reintroduce the 'Create'
> constructor with lower visibility, just implement a second constructor
> with private visiblity.
> It can be useful when implementing singletons and factories to avoid
> some types of misuse by an unattentive coworker...
The problem is that a constructor (in this case Create) in still always
public. So that unattentive coworker can very easily use the default
"public" Create() constructor and by-pass all your custom code in your
"private" constructor.
So that pretty much makes your custom private constructor useless. Plus
if the class was instantiated with the default public Create(), there
could be many other side-effects due to the fact that it by-passed your
custom code.
And yes I know, such a feature would be very handy for Singleton
implementations, but alternative solutions are possible. The same could
be applied to the original poster's code, without creating private or
protected constructors.
A very quick and dirty solution would be to reimplement the public
Create() constructor and immediately raise an exception inside it,
explaining the problem. That way if any developer tries to use that
default constructor, they will get an error - instead of some silent
side-effect later on. Then implement a new public custom constructor
with your desired code.
eg:
TMyClass = class(TObject)
public
constructor Create;
constructor CreateCustom(param1: string);
end;
...
constructor TMyClass.Create;
begin
raise Exception.Create('Please use CreateCustom instead');
end;
constructor TMyClass.CreateCustom(param1: string);
begin
inherited Create; // <- note inherited call to bypass Exception
FValue := param1;
end;
No private or protected constructors are used and you are guiding the
developer to only use the CreatCustom constructor, ensuring your custom
code is executed.
NOTE:
This is still not a perfect solution, but minimized the potential problems.
> IIRC the last time this issue was raised you were on the side for
> removing the warning - my opinion too ;-)
Maybe I learnt from my mistakes. ;-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
