Dave Thomas wrote:

> Eric Jacoboni <jacoboni / univ-tlse2.fr> writes:
> 
>> So my use of 'private', above, don't have the semantic i used to
>> consider, as anyone is able to call a private method simply by creating
>> a subclass.

> In a language where the source code is always available at runtime,
> this seems reasonable. If someone wants to ignore a big hint saying
> "don't do this", then they'll always be able to., and they'll reap
> whatever trouble they deserve :)

Yes, of course... We can't avoid someone to alter the code and remove
'private' in it.  But, in this case, this hacker could not complains
about future class versions that break its code. My notion of
'private' is not aimed at code privacy. When a class developer chooses
to make something private, i think he has good reasons to do so. The
fact that this privacy may be misused (unintentionnaly, in fact) in
Ruby may lead to some strange things if, tomorrow, the developper
chooses to remove this private method, for example.

I think it would be a good think if we can rely on a 'strict privacy'
to avoid these 'possible tricks'.

-- 
Éòic Jacoboni, nil y a 1292443044 secondes.