Ruby’s ability to re-open a class is great! Among other things it
enables separately modularizing issues that cross-cut across multiple
classes. The accessible ‘internal’ points of the class being re-opened
include its existing methods, and modules it includes or classes it
inherits. Through these accessible points we can incrementally and
modularly define a class.
It appears that re-opening a class could have been approximated by:
aliasing the orginal class
creating a new class
defining its methods, modules, etc.
inheriting from the original class
binding the new class to the constant symbol of the original
Of course this would be much more painful.
In exactly the same spirit, wouldn’t it make sense to allow some kind
of re-open of a method, rather than only the current :alias mechanism
(which is itself wonderful after some other languages)? The accessible
’internal’ points could include method-entry, method return, method
exception exit. Through these accessible points we could incrementally
and modularly define a method (or, perhaps more importantly, some
cross-cutting aspect of a bunch of methods across a bunch of classes).
On Wed, Jun 18, 2003 at 06:32:59PM +0900, you CAN teach an old dog … wrote:
In exactly the same spirit, wouldn’t it make sense to allow some kind
of re-open of a method, rather than only the current :alias mechanism
(which is itself wonderful after some other languages)? The accessible
‘internal’ points could include method-entry, method return, method
exception exit. Through these accessible points we could incrementally
and modularly define a method (or, perhaps more importantly, some
cross-cutting aspect of a bunch of methods across a bunch of classes).
In exactly the same spirit, wouldn’t it make sense to allow some kind
of re-open of a method, rather than only the current :alias mechanism
(which is itself wonderful after some other languages)? The accessible
‘internal’ points could include method-entry, method return, method
exception exit. Through these accessible points we could incrementally
and modularly define a method (or, perhaps more importantly, some
cross-cutting aspect of a bunch of methods across a bunch of classes).
It’s not totally clear to me. Could you provide an example usage? I’m
wondering, how you want to distinguish returns and exception return
points. There could be an arbitrary amount of these in any method.
Currently I can only imagine begin (= entry) and end of a method
declaration. Apart from that currently I don’t see practical uses of
this.
Dnia ¶ro 18. czerwca 2003 11:32, you CAN teach an old dog … napisa³:
In exactly the same spirit, wouldn’t it make sense to allow some kind
of re-open of a method, rather than only the current :alias mechanism
(which is itself wonderful after some other languages)? The accessible
‘internal’ points could include method-entry, method return, method
exception exit. Through these accessible points we could incrementally
and modularly define a method
Then changing a method to make the same thing in a different way would no
longer produce an equivalent method - if other code can peek into method and
mess with its internals. I can’t say I like it. It breaks modularity - now
the interface of a method includes details of how it is written.
In exactly the same spirit, wouldn’t it make sense to allow some kind
of re-open of a method, rather than only the current :alias mechanism
(which is itself wonderful after some other languages)? The accessible
‘internal’ points could include method-entry, method return, method
exception exit. Through these accessible points we could incrementally
and modularly define a method (or, perhaps more importantly, some
cross-cutting aspect of a bunch of methods across a bunch of classes).
Or we could make an effort to extend Ruth to do not only
internal->external parse tree conversion but also the other way and then
you can insert code at any point…
However, this would need major update when/if matz changes to byte-code
interpreter.
Regards,
Robert
···
On Wed, 18 Jun 2003, George Marrows wrote:
In exactly the same spirit, wouldn’t it make sense to allow some kind
of re-open of a method, rather than only the current :alias mechanism
(which is itself wonderful after some other languages)? The accessible
‘internal’ points could include method-entry, method return, method
exception exit. Through these accessible points we could incrementally
and modularly define a method (or, perhaps more importantly, some
cross-cutting aspect of a bunch of methods across a bunch of classes).
