> On 12.03.2018, at 20:26, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 12-03-2018, at 11:48 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> well, I think the compiler complains if you send messages starting with 'pvt' to something other than self, right?
> 
> That's the wrong way round though; it requires the sender to know too much. And it can't work to stop (ab)use of #perform: type sneakiness.
>> 
>> Other than that, I think there's too much merit in "vars are private, messages are public" than to introduce an outright restrictive messaging model.
> 
> Personally I'd be more inclined to go for "methods are private unless explicitly set to public" as a way to aggressively make people think about what they're doing!

welcome to java world, where everyone is making everything final, because, why yes, nobody should use that but my code!
I've been bitten by that, and I've always appreciate the kind of responsibility that Smalltalk gives to the client of objects: "you send that message, you're gonna be responsible for it".

It's more about educating Smalltalk programmers about the responsibility they bear. We try that in our courses here, and, sure, some people are like "what the heck, I'm just do whatever", which clearly would be helped against by private methods. But I strongly resist being dictated by this minority of Smalltalk user. Rather, 
 - Better tooling
 - Better documentation and
 - Better live interaction
are IMHO the keys here. Otherwise you end up with TypedSmalltalk, because, well, yeah, the compiler surely knows better than you what your program should look like, and while we're at it, we're gonna pretty print your methods the way the system prescribes no matter what style is actually appropriate for the code you've written.
[side note]
tim, I hope you understand I'm not ranting about you, au contraire.
[/side note]
Where was I? Oh yeah, the safety argument.
There's a German road security specialist who says, the way to make driving the safest is to put a point stick right on the driving wheel so that should you brake too hard, it'll puncture your skull. That way, nobody would ever dare to drive too fast or dangerously. Casualties  would certainly drop, considering everything.
[side note]
No, I'm not making this up
[/side note]
The other method he suggests is better education and better awareness, combined with better helpers (viz. tools)

I'd rather have the latter, in Smalltalk, than a pointy stick. :)

> 
>> 
>> You'll never know what part of your objects interface is gonna being needed down the road.
> 
> Well you ought to at least think about it a bit, and the nice thing is that stuff can be changed, what this being Smalltalk.

That's the nice thing about a living system: you can experiment with it and see what actually happens. that supplements upfront thinking with on-the-go experience. I think keeping messages open is still key here.

> 
> And while I'm being all dictatorial, I really hate to see code like
> 
>  self foo bim baz wibble at: weeble state count + 1
> 
> ie chains of accessors that imply far too much knowledge of the type of what you get returned. Should be more like
> 
>  self wibbleStateAt: weeble nextState
> 
> with suitable delegations though whatever foo is, and its baz, and its wibble, and so on.

Clearly, Law of Demeter! We teach that our students every year in quite some detail with quite some emphasis.

But I think both points are orthogonal here. :)

-tobi


> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: FA: Failsafe Armed

HCF!

> 
> 
>