[Grace-core] Fwd: Some notes on pattern matching on the wiki

[Andrew P. Black]

On 5 Jul 2011, at 20:26 , James Noble wrote:

>> In which case what does "self." really mean? I think any syntax that looks like <receiver>. should be dynamic and lack of receiver is lexical. It satisfies my need for clearly signalling what's going on by just looking at the thing (not needing to look at the context) while providing fairly succinct syntax.
> 
> 
> I think AmbientTalk more or less does this, and Andrew has been advocating for this design.
> But, this seems to require that instance variables and methods - "private" or not - 
> must be accessed via self, Python style, because they can be overridden in subclasses.

No, I don't think so.  If "private" means "accessible only within this object" then instance variables and methods are lexically in scope inside the object constructor, and can be accessed without self — and consequently without dynamic dispatch.  And, consequently, they can't be overridden (which is why they are private).

Conversely, if you want a subclass to be able to override your method, or your instance variable, then you should use self.  This means that a method is requested and bound dynamically.

Smalltalk code does this most of the time right now, and is very readable.  The only place where this rule would be stricter than Smalltalk is in requiring the use of method request (with self.f) in a sub-object to access a field f of a super-object.  The pay-off is that f might not be a field — f can change from a calculated to a stored "feature" and the sub-object wouldn't care.

> 
> As the latest blog post says, we're looking at the Ruby _semantics_ of "private" -
>  accessible only on the "self" instance - rather than the C++/Java meaning - accessible within the class.
> confusingly, Ruby goes one further: private methods *can only* be called with an _implicit_ receiver.  gulp.