[erlang-questions] Why isn't erlang strongly typed?

[Isaac Gouy]

--- Richard O'Keefe <ok@REDACTED> wrote:

> 
> On 5 Nov 2008, at 12:33 pm, Isaac Gouy wrote:
> >> Traits don't disallow access to state.
> >> They disallow *direct* access to state.
> >> They can use as much state as they want,
> >> provided they do so by calling methods from the
> >> class they are extending.
> >
> > In other words, traits disallow access to state and require methods
> in
> > the class (not in the trait) for access to state :-)
> 
> Many Smalltalk masters recommend what's called "self-encapsulation"
> where ANY class should encapsulate access to its state variables in
> a small handful of methods and ALL other methods should use those
> to access state rather that directly referring to instance variables.

Famously Alan Snyder in "Encapsulation and Inheritance in
Object-Oriented Programming Languages" 1986

http://citeseer.ist.psu.edu/old/snyder86encapsulation.html


> Nobody says that this disallows access to state!

Why would they when the class has state and it is accessed? :-)


> On the contrary, people talk about calling such accessor methods
> as "access to [state] data".  See
> http://www.martinfowler.com/bliki/SelfEncapsulation.html
> for an example of this usage.

The thing to remember about "accessor methods" in Smalltalk in contrast
to "accessor methods" in Java, is that in Smalltalk they aren't
"accessor methods" just methods - there's no well understood convention
that 'they shall access state'.


> Traits don't have any state of their own to access,
> so they can hardly be said to disallow access to what does
> not exist.  For access to the state of the class they are
> bound in with, traits rely on self-encapsulation, not as
> a way of disallowing access to state, but as a way of
> ENABLING it.

Traits don't rely on "self encapsulation" - that would make the trait
the "self" in "self encapsulation". 

Traits rely on a separate class providing "required methods", whether
those "required methods" do in fact access state in the separate class
is entirely up to that separate class.


> To call this extended use of self-encapsulation
> "disallowing access to state" would be rather like calling
> windows devices for disallowing access to light.

The window is in the class not in the trait.

Anyway I doubt this is interesting to this audience - not even Luke
Gorrie ;-)