Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Both ways make some sense. "Normal" way is to extend the interface (so making a method public looks more natural). However, to support encapsulation one may create a "view", where only some method are visible. BP may be misguided here, but ability to make method private sometimes may do as substitute for views. Limiting visibility have nothing to do with polymorphy -- the method still have to be in VMT, but may called only where static type (= interface) allows.
But such a "view" could easily be bypassed by passing the object (polymorphically) to a formal parameter of the parent type, so I don't see what it gains, apart from confusion. Or actually worse, since you'd allow a private method to be called from outside (without dirty tricks, just through the VMT in a "public" place).
The same is true for real views (or restricted types). The point is that any code which is allowed to know parent type is allowed to call the method -- you restrict access to the method by restricting access to the parent. In EP modules you may export only child, so only dirty tricks will get you at the parent.
Then there's no point making the parent method public in the first place.
Consider: A - public B(A) - private C(B) - public "view"
Still, what's the point in declaring A's method public if you don't export A?
I agree that (real) views can be useful, but IMHO they don't fit well into the BP model. They may require to go through a parent type in order to access certain feature, which is never required otherwise in BP.
(Of course, when we later add views as part of OOE, it may be possible that they can be combined with BP objects, but this would be an explicit mixture of dialects, whereas in this example we're on pure BP syntax with (as it seems) unintended strange effects.)
And even if not strictly enforced making method provate still serves as documentation and catches some mistakes. In short -- I think that there are good reasons to turn public method into privete method. If (when) we implement Object Pascal views we will have better apporach, but it still may be good idea to remain BP compatible.
BP compatible? Including the strangeness of an object having two methods of the same name (not as parent methods, but in the same type, see original mail)?
Well, BP behaviour is crazy. AFAIKS they just do not export private methods. IMHO correct (and more useful) is to export the method as private so an attempt to call it produces diagnostic.
Yes, that's what GPC does.
I wonder what BP does if a method is virtual? Do they just ignore `private'?
Seems so. This code says `b.p' twice:
unit U;
interface
type a = object constructor c; procedure p; virtual; end;
b = object (a) private procedure p; virtual; end;
implementation
constructor a.c; begin end;
procedure a.p; begin WriteLn ('a.p') end;
procedure b.p; begin WriteLn ('b.p') end;
var v: b;
begin v.c; v.p end.
program Foo;
uses U;
var v: b;
begin v.c; v.p end.
Now, feature that behaves differently depending on dialect should be avoided, so I agree with you -- it is better to give error message at definition time by default.
Yes, I think it's better to leave the rest for (future) real view declarations.
Frank