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

[James Noble]

> Perhaps it is more accurate to say that with nested classes there is no way to give an explicit receiver for messages sent to objects in the enclosing class:
> 
> class Outer {
>  void out() { ... }
>  class Inner {
>    void in() {
>      out(); // this.out() does the wrong thing
>    }
>  }
> }

So in Newspeak (or apparently Ceylon) , you could write "outer.out()" to call the message on the enclosing class?

Java has a variant of this with the Outer.this.out()  syntax? 

or am I missing something here?

>> how ugly is it to have to write self._foo  and self._bar(x,5) all the time to access "private" stuff?
> 
> very ugly. The kind of ugly that would put people off, primarily because it would require typing "self." a whole lot, and would totally pollute the code ("self." is all you would see when looking at it). It's this kind of thing that puts people of BEGIN END instead of {}. (IMHO of course)

Python requires self.x to access instance variables and instance methods.
The (whole 200-odd) lines of Grace code I wrote for pattern matching (in the svn)
uses self on about 26 lines / 250. 

It certainly makes things clearer - although I do like the Java/Self style of an "implicit" self.

>> (an evil option could allow "_" as a substitute for "self." for private things, but that seems several more steps too far)
> 
> 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.

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.

I'd still like to keep message request or evaluation rules as simple as possible. 
and to *decouple* access specifiers from the method request  / "lookup" logic.

James