2008/11/27 Ramon Leon <ramon.leon at allresnet.com>:
>> So you are lamenting loss of encapsulation (a restrictive feature) in
>> the first paragraph, and decrying loss of freedom to restrictive
>> features in the second. Come on, pick one.
>
> Because I consider encapsulation something that exists between objects, not
> between super and subclass.  I don't consider that a conflict, interesting
> that you do.
>
>> If you don't want the
>> author of a class deciding how you might decide to use it, how can you
>> put up with him deciding what instance variables are off-limits and
>> have no public accessors?
>
> Again, the object class divide; he can't, in Smalltalk, restrict me from
> seeing instance variables if I subclass his class.  I like it this way.
> When I'm building a new class it's up to me whether to choose to use
> inheritance or not and if I choose to do so it's because I want to share
> code or extend or specialize that class and I want direct access to anything
> in that superclass.  My class is not his class and if I do something that
> makes my classes instances misbehave that's my problem, not his.
>
> The public interface of instances of his objects however, is his problem and
> he has every right to encapsulate and protect the implementation of his
> instances.  There simply is a difference, to me at least, between using
> someone else's objects, and using someone else's classes as a template to
> build my own objects.  I accept encapsulation as beneficial and necessary in
> the former case but as harmful and restrictive in the latter.
>
> I base this judgment on the vocabulary I find myself muttering in each case,
> usually profanity in the latter case while I hunt down source code to change
> the original authors access modifiers.
>
>> Indeed what I had in mind were Newspeak-style access modifiers
>> combined with message-based slot access. Their combination in fact
>> improves encapsulation. And no, they don't lead to final classes.
>>
>> Cheers,
>>
>> --Vassili
>
> They certainly start down that road, final and sealed are just as much
> access modifiers as public, private, or protected; however, if not applied
> zealously and taken too far (i.e. final classes), I agree it's not a bad
> solution.  I would prefer not to have two ways to access instances vars so
> if protected accessors were the solution I'd want them to replace all direct
> instance variable access, even within a single class so slots make perfect
> sense.  But at this point, we're not really talking about Smalltalk any
> more.
>
> I won't pretend to be a language designer or say I know what the perfect
> balance of features is, but I rather like the balance Smalltalk struck with
> no access modifiers, public methods, protected instances variables, and
> trust in the programmer.
>

Concerning security models and principles it is based upon, i very
like a simple & powerful security model used in E (Erights).

>From http://www.erights.org/elib/capability/ode/overview.html

----
Capability Security. The Granovetter Operator becomes a security
primitive given the following constraint: If Bob does not already have
a reference to Carol, Bob can only come to have a reference to Carol
if a third party, such as Alice,

    * already has a reference to Carol, and
    * already has a reference to Bob, and
    * voluntarily decides to share with Bob her reference to Carol.

Adding this property to an object system transforms it into a
capability system. In a capability system, only connectivity begets
connectivity. In a capability system, an object's authority to affect
the world outside itself is determined solely by what references it
holds, since the only way the object can cause an external effect is
to send a message via one of these references. Consequently, the
mechanics of reference-passing determine how authority can change over
time.
----

Its easy to show, that access modifiers or class sealing is not the
answer to security.
Simply do not give away an object references to untrusted code which
would allow it to operate directly with critical system resources.

In short, a principle is very simple: you can't break things which you
cannot reach or see.

> Ramon Leon
> http://onsmalltalk.com
>

-- 
Best regards,
Igor Stasenko AKA sig.