On 5/22/07, Sam Liddicott <[EMAIL PROTECTED]> wrote:
* Flávio Etrusco wrote, On 21/05/07 22:44:
> On 5/21/07, Lepidosteus <[EMAIL PROTECTED]> wrote:
>> One thing I dislike is the poor abstract implementation. I don't see
>> one good reason to let abstract class be instantiated...
>>
>
> Totally agreed.
> And I'd like it so much if FPC would allow one to declare a class
> 'abstract' even if it didn't contain abstract methods...
>
> Final methods and readonly/final members would also be sooo nice ;-)
They would be a wicket sin.
I had so much trouble in the Delphi 1 days because so many VCL methods
were needlessly declared "private" instead of protected.
I found hacks round it, of course, but the priorities of the
component-set developer often don't match those of the user who is also
a developer. private and final are a usually poor substitute for
respect and good communication.
Sam
Well, I guess maybe I should reply in private, but this way people
could think I agree on Sam's points, but it's not true and I hope my
opinion can be of some interest ;-)
VCL is definitely an infuriating example of usage of visibility to
cripple functionality, but this is/was obviously a design decision and
not bugs. IMO it was a way of giving out to the users the power of
having the source code but avoiding VCL being extended or modified in
ways Borland wouldn't like.
If not, they wouldn't have gone the great lengths they did to keep
people from recompiling the VCL (after changing any visibility they
wanted).
Visibility and mutability controls both have a big role in avoiding
several classes of programming errors, and anyway (their
non-existence) couldn't have helped a single bit against restricting
licenses.
But sure, I wouldn't oppose a compiler directive to enable some dirty
tricks against the 'private' visibility ;-)
Cheers,
Flávio
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
