[Grace-core] More thoughts on modules

James Noble kjx at ecs.vuw.ac.nz
Tue Jun 14 04:01:40 PDT 2011


> A large number of instructors (including me) consider teaching (enforceable) abstraction as key.  

yep me too.

> One of the many reasons that I have never considered teaching with Python was the lack of support for information hiding.

I didn't know about that, but yes it is another big reason not to take on Python
(at least not after the 1st semester)

> Looking up information on information hiding and dynamically typed languages, I found that Ruby has an interesting variant of information hiding.  If you declare a method to be "private" then it means (unlike Java and C++) that the method cannot be called with a receiver.

I like this - it's close to Smalltalk, easy to explain, and arguably the *right thing*
(Self actually had a more complicated rule which it eventually abandoned,
required because of multiple delegation semantics etc)

perhaps we can even use the annotation/attribute/metadata syntax to declare this?
or private can be the default, public is the annotation.
(I think that's what ceylon does, it just has one "shared" annotation", which I'm still not sure precisely what it means)

> Realizing that this does not provide everything that was in your OOPSLA paper, it seems like it is a nice first step toward providing support for information hiding.  Is there any reason not to go with something simple like this?

I'd prefer something simple like this.
If we can add in private classes, I'll be over the moon.

the other good thing about this model is that it works well with security models
(like MIller's "Object/Capability" model) --- which is all about per-instance restrictions.

ruby also takes "protected" to mean "accessible to all instances of class & all subclasses"
not sure if we want to do that (or if it should be called protected!)  but I remember a
discussion with Dan Grossman on objects vs ADTs: this would facilitate that...

> Kim
> 
> P.S. I prefer to distinguish encapsulation from information hiding, though my definitions may not be the most popular ones.  For me, putting instance variables and methods together in a class is an example of encapsulation -- essentially putting them in one "package".  Information hiding is the notion of limiting access to features -- usually those already encapsulated in some way.  I find it useful to have different words for these two.  Can we agree on a terminology that separates these two notions?

argh! 20 years of terminological confusion!


More information about the Grace-core mailing list