Self and fields in blocks

26 views
Skip to first unread message

Phil Hagelberg

unread,
Jan 11, 2011, 2:05:01 PM1/11/11
to mi...@googlegroups.com
One of the main pain points that I've come across so far in Mirah is
surrounding blocks. A common antipattern is needing access to instance
variables inside the blocks, but since blocks actually compile to
separate classes, instance variable lookup doesn't work. In addition,
self references inside the block refer to the closure object rather
than the enclosing object. This is probably my biggest pain-point
(apart from builds) in Mirah right now, and I'm wondering what could
be done about it.

Charles mentioned in IRC that Groovy has multiple "self" notions
depending on if you want to refer to the closure or the surrounding
object. Personally I don't see much use in accessing fields and self
of the closure object itself, but maybe there's a use case for that
which I don't see. It might be nice to try to emulate Ruby's approach
and shield programmers from the fact that closures are separate
classes, but (a) how hard would that be to implement? and (b) can that
be done seamlessly, or will it be a leaky abstraction? If it can't be
done seamlessly with "self" and "@var" then it may be necessary to
introduce new ways to reach into the surrounding object.

Thoughts?

-Phil

Rib Rdb

unread,
Jan 11, 2011, 2:35:00 PM1/11/11
to mi...@googlegroups.com
We need to get inner classes working correctly.  The idea is that the inner class stores the outer self.  For any self call or field reference it first checks to see if it exists in the inner class, and if not it checks in the outer one.  I think that's probably enough for the general use cases.  Java also has syntax for referring to this from a particular outer class.  We should support that eventually.

The scoping changes probably aren't too hard. This seems very similar to static imports -- I don't remember exactly how I got those working but we should be able to do the same sort of thing.  It gets trickier though when we deal with private things (such as instance variables), because we also have to generate hidden accessor methods.  Plus we should also support inner classes inside inner classes.
Reply all
Reply to author
Forward
0 new messages