Mark Morgan Lloyd schrieb:
You are of course entirely right: from the POV of protecting against silly mistykes it's entirely adequate to have a validation parameter, even if it's not used for anything else.
If only one initialization is sufficient, the property setter can reject any further changes, after the value has been set to something other than "uninitialized". I use such protection frequently, for properties which cannot be changed after initialization of an object.
I was originally thinking about it from the POV of bare-metal protected-mode code, where you could explicitly bind a procedure to ring 2 thus protecting it from ring 3 access.
This only defers the authorization problem, to controlling ring transitions. You can introduce a global "RingLevel" variable, checkable in every protected procedure. Then everything depends on controlling the write access (for rights elevation) to that variable. IMO this doesn't help much, since when a subroutine is allowed to increase the ringlevel for one purpose, it will be allowed subsequently to call *all* other protected subroutines as well.
Another idea: every creator of an object can keep the object private, so that nobody else can access it. This is impossible for an TFrame, which is listed in the public Controls[] and Components[] lists. In this case another "lock" object can be used, known only to the creator and the protected object/procedure, as a spoofing protection.
Or you use "private" or "implementation" clause visibility. Then only code inside that unit can access such a variable or field.
DoDi -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
