[Cuis-dev] Why can't you send to super on private (pvt*) methods?

[Andres Valloud]

That sounds like a poor man's approach to real modularity.  These kinds 
of "improvements" will give the impression of progress, but later will 
get in the way of the people that will come later to do a finished product.

The problem here seems to be "modularity", but the drawback with this 
approach is that it presumes what is a correct way to design things 
irrespective of circumstance.

And let's not forget "private", "protected", and even "final" mean 
different things to different people.  Sure, "private" or "protected" 
make sense from a user perspective, but they royally get in the way the 
moment you're in charge of implementing the kernel system itself.

In short, the flaw in this reasoning is that it confuses "users of the 
system" with "developers of the system", and these two have different needs.

On 6/11/19 04:56, Hernan Wilkinson via Cuis-dev wrote:
> 1) super pvt* it is not allowed because "private" parts of a class are 
> only visible to its instances, at least that it is how c++/java and the 
> like treat private stuff (methods, vars, etc). So in Java you can not do 
> super.prvt*().
> The behavior you are proposing Phil would be like "protected" in those 
> languages. In fact, we could say that inst. vars. in Smalltalk are 
> protected in the c++/java parlance.
> So, my guess is that the current restriction on super pvt* came from 
> that understanding "private".
> Having said that, I see no problem to change that restriction and treat 
> pvt* messages as they were protected although it will be confusing to 
> explain when compared to other languages. I think it would be better in 
> that case to have prt* (protected) instead of pvt* but that would 
> generate a migration problem...