Squeak vs. privacy

Hey, all,

        I thought the "Tim vs. Accessors" was great. I learned a lot. Everybody  
stated their positions without anyone getting into a high dudgeon, even if  
no minds were changed. And as I originally suggested, the root problem  
seems to be lack of privacy for accessors. (Although I've been toying with  
the argument that if the inst-var needs to be accessed with an accesor to  
encapsulate it from the rest of the class, perhaps IT needs to be its own  
class.)

        Anyway, while I'm a long-time foe of the "private" designation ("no one  
shall ever need to touch this feature again"), I do like the various forms  
of scoping allowed by other languages: protected, public, even published  
(which is a cute trick for a non-reflective language, not really useful in  
Smalltalk).

        At the end of the thread, Tim points out some of the challenges with  
implementing scope, and some kinds:

Class-to-Instance
Instance-to-instance

with which I wholeheartedly agree.

        Tim adds:

"Privacy violation
What should happen? An exception? A resumable one? Core dump?"

        I would sugget a DNU should occur.

        My next question, then, is couldn't this be as simple (from the user's  
perspective) as placing methods in specific categories, for example:  
strict private (for self only); private (for class and maybe sibling  
access); protected (for ancestors)? Maybe that's too complicated, dunno.

        My gut feeling is that there's tremendous potential benefit to this; that  
greater encapsulation might help with the rot. But certainly Smalltalk is  
old enough have had something like this done before, so maybe I'm mmissing  
something.

        ===Blake===

>         My next question, then, is couldn't this be as simple (from the user's
> perspective) as placing methods in specific categories, for example:
> strict private (for self only); private (for class and maybe sibling
> access); protected (for ancestors)? Maybe that's too complicated, dunno.

Try creating some categories for your own code. Then extend the
SmallLint tools to give you feedback on usage.

I'm personally very opposed to method access control (just from bad
personal experience in Java). I've always found that calling a method
that is in a private category from outside the object is enough of a
code smell for me. No exceptions necessary.


>
>         My gut feeling is that there's tremendous potential benefit to this; that
> greater encapsulation might help with the rot. But certainly Smalltalk is
> old enough have had something like this done before, so maybe I'm mmissing
> something.
>
>         ===Blake===
>
>

+1

On 10/16/07, David Mitchell <[hidden email]> wrote:

To make your methods really private, without changing anything in
smalltalk , you can just create a new class with your 'private'
methods, and add instance var to your original class, which will hold
instance of this class.
Make no accessors to this inst var , and in own code you can freely
send messages to this 'private' instance.

Of course, this haves own glitches, since you need to split your
object state and behavior over 2 classes, but i don't think this is
really a problem.
It does what you want - makes part of your object behavior private and
invisible outside, so what the difference?

And i don't think that this is worth at all. Try think different, try
use best of ST powers and don't try to apply usage patterns from other
languages.
This is common mistake trying to use same approaches for different
environments.
I think that ST have enough features to provide privacy.

--
Best regards,
Igor Stasenko AKA sig.

On 10/18/07, Igor Stasenko <[hidden email]> wrote:
>
> And i don't think that this is worth at all. Try think different, try
> use best of ST powers and don't try to apply usage patterns from other
> languages.
> This is common mistake trying to use same approaches for different
> environments.

A big +1.  This is the number 1 mistake most people make evaluating
new languages.  They go try to do what they used to do in their old
language, in the same way they used to do it and go "see!  I knew my
old language was better!".  The main reason for trying out a new
language should be to play to it's strengths and see where you get.

On 18-Oct-07, at 9:42 AM, Jason Johnson wrote:

Well *I* would like a way to make private methods workable and  
*nobody* could reasonably accuse me of that mistake. I've done  
nothing but Smalltalk for.... err.. 25 years or something like that.

The problem is practise with suggestions to just do it right is that  
when a lot of newcomers arrive they don't know what 'right' is. If no  
one ever notices they're doing things not-right and corrects them,  
they never learn 'right'.

Private methods would help reduce the incidence of an important class  
of not-right IF
- they were implemented correctly
- they were actually used in the image to illustrate their value
- they were documented


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh, as he realised Piglet was undercooked.

On 10/18/07, tim Rowledge <[hidden email]> wrote:
>
> Well *I* would like a way to make private methods workable and
> *nobody* could reasonably accuse me of that mistake. I've done
> nothing but Smalltalk for.... err.. 25 years or something like that.

In this instance I was simply pointing out this fact in general.  I
didn't have in mind any of the context around it. :)

On Thu, 18 Oct 2007 09:42:04 -0700, Jason Johnson  
<[hidden email]> wrote:

Well, as I said when I introduced the topic, I was toying with this very  
idea.

Should one have to work so hard to make private methods?

It does nothing for other forms of protection, such as allowing ancestral  
access, sibling access, class access.

Maybe that's not important, of course.

> I'm personally very opposed to method access control (just from bad
> personal experience in Java). I've always found that calling a method
> that is in a private category from outside the object is enough of a
> code smell for me. No exceptions necessary.

+100 !

> Should one have to work so hard to make private methods?

In an open-source Java system, what happens when developers need
access to something declared "private" or protected?  Answer:  They
loosen the visibility to what they need and recompile.  It's not
"protection" at all (again, assuming an open system whose intent is to
be modified).  It's more just rigid "documentation".

In Squeak, methods in "private" category mean, "use only if you know
what you're doing, and at your own risk".

> It does nothing for other forms of protection, such as allowing ancestral
> access, sibling access, class access.
>
> Maybe that's not important, of course.

Well, it's certainly not worth the complications (just understanding
and remembering the subtle semantics is too much), and not conducive
at all to a dynamic system.  It literally is "early binding".