Neven wrote:
> Is this all so a common property editor can be used?
In theory, FSQL could be declared as a TStringList but then a GetSQL method
would be needed since the property SQL and private member FSQL are not type
equivalent. It would be trivial to implement (it just assigns FSQL to
Result) but it doesn't buy you much other than allowing you to avoid casts
to call any TStringList specific methods within TQuery.
It would be a nice relaxation of the Delphi property declaration rules to be
allowed to use a TStringList member as the read/write value for a TString
property (or more generally - to use a derived instance to back a read/write
property of a base instance).
Eiffel has such type relaxation rules - you can change the type signature of
a virtual method that returns a base class instance to return a derived
class instance in the derived class declaration.
i.e.
TBase = Class
..
function Clone: TBase; virtual;
..
end;
TDerived = Class(TBase)
..
function Clone: TDerived; override; <--- note type change
..
end;
This is purely a syntactic difference (i.e. it doesn't change the code
generated) but it does allow TDerived code to avoid being cluttered with
unecessary casts when calling Clone upon itself internally.
With Eiffel being a Pascal-like language, Delphi would do well to observe
it's OO and software engineering features such as requires, ensure, and
invariants (programming by contract). I did always hate the Eiffel
constructor syntax though.
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
