> > Ahh now this is making more sense... It's possible I suppose that you
> > should be able to set this type of restriction in your published
> > properties... Then the compiler can scan the property values from the
> > RES file and warn for any properties that break a constraint.
>
> Currently for some of these things I raise exceptions at runtime and halt
> execution, but its a little unpleasent....
True and currently this is what I tend to do with unfinshed routines... Although it
would be nice if the {$WARN XX} that I suggested was only output at the end of
compile-time after the compiler was able to assess whether that source-line was
reachable... Otherwise it's not necessary to get a warning...
> Delphi gives us the ability to visually extend our development
> environment, extend the property inspector, extend the IDE, why not also
> the ability to extend the compiler. If someone was to download my
> unitsystem componets to use in their own app, they might overlook setting
> those fields, or in moving components from form to form they may 'loose'
> the link that goes unnoticed, whilst its in the docs and the programmer
> knows there supposed to be linked, its not always obvious when they loose
> that link, so a compiler warning would be good.
>
> The problem I see with your $WARN compiler directive (as it stands) is
> that there's no checking to see if it should warn, unless you did:
>
> if self.unitsystem = nil then
> begin
> {$WARN warning}
> end;
>
> Also, putting that directive in the property set code doesn't (in my mind)
> sit in the right place, it wants to be somewhere that is seperated from
> the actual code itself (you dont want it in the executable, much like
> property editors).
>
> Maybe we could add something that, like a property editor, registers
> itself and is parsed before the compile, and you could raise a "compiler
> exception":
>
> if component.unitsystem = nil then
> raise TCompilerWarning.Create(Format(
> '%s.UnitSystem is nil.',[component.name]));
I suppose this could be a 'RegisterConstraints(TargetClass,[ConstraintClasses]);' idea
but the compiler would need to pass every component through the list of constraints
before completing compilation. It should also then be possible to have critical errors
as well as warning using a
TConstraintTestResult = (ctrOK,ctrWARNING,ctrERROR);
TConstraintObject
property TargetClass :TClass;
function GetConstraintDescription:String;
function Test(O :TObject; var Message :String):TConstraintTestResult;
end;
if GetConstraintDEscription returned a string in the same form as Short/Long hints
then a Checkbox listview
could be provided in the compiler options window to enable disable certain constraints.
Whilst I agree in concept with your idea it limits use to registered classes and
removing the
code from the class definition increases the complexity of maintaining the code. The
compiler
certainly shouldn't add code to the excecutable but it's a shame the the warning can't
be
attached to the property it's testing.
I'm uncertain at this point as to whether the benefits outweigh the added complexity
given that the final product does not benefit in either efficiency or functionality
(though
it may benefit from tighter timeframes if such programmer faults are common).
Cons:
Slower compilation.
Higher maintenance complexity and initial complexity of developing constraints
Possibility for spurious messages if a programmer intends to rectify a constraint
at runtime.
Pros:
Possiblity to reduce programmer errors that are usually only detectable at
run-time.
Shorten learning curve for 3rd party components through 'hint' style warnings.
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---------------------------------------------------------------------------
New Zealand Delphi Users group - Offtopic List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
