2.1.1 new protected

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.1 new protected

Florian Klaempfl
Marco van de Voort wrote:
>> It is ugly, produces warnings and is possibly forbidden in FPC 2.1.1 (I don't
>> know). A more elegant solution would be to have something like 'friend units'
>> where protected class members are visible:
>
> I wonder what the use of making a private/public/protected distinction is in
> the first place, if USES'ing units can override it at will.

Little :) Borland realized this as well and added the strict private/protected ...
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.1 new protected

Martin Schreiber
In reply to this post by Marco van de Voort
On Sunday 13 August 2006 13.27, Marco van de Voort wrote:
> > It is ugly, produces warnings and is possibly forbidden in FPC 2.1.1 (I
> > don't know). A more elegant solution would be to have something like
> > 'friend units' where protected class members are visible:
>
> I wonder what the use of making a private/public/protected distinction is
> in the first place, if USES'ing units can override it at will.
>

In a tool library:

public -> interface for the library users, use it without knowledge of the
internals.

protected -> interface for the library developers, use it if you know what you
do. Use strict protected if you want to secure encapsulate things.

private -> secure encapsulated class items.

Note that I had to use 'cracker classes' in MSEgui to access private FPC class
items to implement workarounds...
I must repeat:
It is not possible to develop a complex system in a clean single class
hierarchy, especially not if you use foreign units which are not under your
control . I know it because I tried it...

Martin
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.1 new protected

Michael Van Canneyt


On Mon, 14 Aug 2006, Martin Schreiber wrote:

> On Sunday 13 August 2006 13.27, Marco van de Voort wrote:
>>> It is ugly, produces warnings and is possibly forbidden in FPC 2.1.1 (I
>>> don't know). A more elegant solution would be to have something like
>>> 'friend units' where protected class members are visible:
>>
>> I wonder what the use of making a private/public/protected distinction is
>> in the first place, if USES'ing units can override it at will.
>>
>
> In a tool library:
>
> public -> interface for the library users, use it without knowledge of the
> internals.
>
> protected -> interface for the library developers, use it if you know what you
> do. Use strict protected if you want to secure encapsulate things.
>
> private -> secure encapsulated class items.
>
> Note that I had to use 'cracker classes' in MSEgui to access private FPC class
> items to implement workarounds...
> I must repeat:
> It is not possible to develop a complex system in a clean single class
> hierarchy, especially not if you use foreign units which are not under your
> control . I know it because I tried it...

No. It just means the classes are designed wrong.

If you need to access directly private class fields, I think there are serious
design flaws in your code.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.1 new protected

Matt Emson

> No. It just means the classes are designed wrong.

Very true. There are a number of places in Delphi's VCL where this is
true... for D5 at least.

> If you need to access directly private class fields, I think there are
> serious design flaws in your code.

Class "crackers" only give access to protected members - well in Delphi at
any rate.

type
  TCrackControl = class(TControl);

var
  _label: TLabel;

...

  TCrackControl(_label).Text := 'I can do this now';

This is pointless as the Text and Caption of a label map to the same
internal data, but using this method it demonstrates access to internals.

As to why Borland made a distinction between Caption and Text properties..
another debate ;-)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12