From: Aaron Scott-Boddendijk [mailto:[EMAIL PROTECTED]]
> Whilst this may stop the code reaching the constructor the compiler will
> still compile a line in a different unit
> x := TDescendant.Create;
> even if the descendant does not declare a constructor... The program will
> run using the code of the constructor one further step up the class-tree
> producing unpredictable results. Hence you're back to a run-time ident
> problem with unpredictable results...
You learn something every day...
I hadn't seen that before, mainly because when I had previously wanted to
hide the original constructor it was because I had a couple of overloaded
descendant constructors, eg.
type
Ty = class(Tx)
public
constructor Create(i: integer); overload;
constructor Create(c: char); overload;
end;
Now in this case, if you have Ty = class(TObject), the line
y := Ty.Create;
will be allowed, since TObject.Create is automatically overloaded with the
other two creates, forcing you to reimplement Create and raise an exception,
as you suggested. But if Ty descends from Tx as above, you get a compile
time error "Not enough actual parameters".
> Better to make the public constructor
> produce an exception and have a private constructor perform valid
construction
> from the class method that validates the construction process.
Having a compile time error is preferrable, because a runtime exception
allows developers to make a mistake calling Ty.Create which might not be
picked up until testing, or possibly even later. I take your point about
the case in question though.
Cheers,
Carl
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
