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
<gra...@mastermaths.co.za> 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.
> 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

Reply via email to