Ruby has a similar functionality that lets you define methods on an instance
object. Really, its how class methods are specified, you just put the class
name as the name of the object. Here is an example:
a = Object.new
def a.foo
puts "foo and #{self}"
end
They will stay on the object as long as the object exists. So, if its a
scoped variable, it will go away when you leave the scope.
--
John Harrison
On Wed, Apr 21, 2010 at 7:49 AM, Andrew Whitworth <wknight8...@gmail.com>wrote:
> This idea strikes me as being extremely similar to C#'s extension
> methods, a feature that I've found to be particularly beneficial in
> many cases. The fact that these methodicals are lexically-scoped is
> especially nice, and the fact that they can be applied post-hoc to
> arbitrary data items that have no prior support for them (like Parrot
> objects) would be very nice to have on Parrot in particular where
> language interoperation could be a big deal in the future.
>
> +1
>
> --Andrew Whitworth
>
>
>
> On Wed, Apr 21, 2010 at 3:16 AM, Stefan O'Rear <stefa...@cox.net> wrote:
> > (The following describes a proposed extension to Perl 6, methodical
> scoped
> > operators or methodicals for short. It is written in the present tense
> for
> > simplicity but should be understood as the future conditional.)
> >
> > Normally, when you write a method call, the definition of the method is
> > entirely in the domain of the receiver's class:
> >
> > $object.make-me-a-sandwich; # $object gets to decide what this means
> >
> > However, this is not always how things work.
> >
> > $object.WHAT; # Larry says that WHAT should return the protoobject
> >
> > WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics
> > (although not implementation) defined by the language itself. Currently,
> Perl 6
> > fakes this by having all values inherit from Any or Mu or Cool, which
> define
> > the basic, overridable versions of these method-like operators. This
> cheat
> > actually works pretty well in a homogeneous environment, but it fails if
> we have
> > to consider objects from outside Perl 6.
> >
> > $parrot-array.WHAT; # Method WHAT not found for invocant of type ...
> >
> > The problem here is that scopes are conflated - WHAT is defined by the
> > language, which is approximately a lexical scope, while methods on an
> object
> > are in some entirely different scope.
> >
> > A methodical is an operator which syntactically behaves as a method but
> is
> > subject to scoping rules. Methodicals are defined using the ordinary
> method
> > keyword, qualified with my or our. (TODO: This seems the most natural
> syntax
> > to me, but it conflicts with existing usage. Which is more worth having
> on
> > it?) Methodicals do not need to be declared in classes, but they should
> > generally have declared receiver types.
> >
> > {
> > my method make-me-a-sandwich(Num:) { ... }
> >
> > 2.make-me-a-sandwich; # calls our method
> >
> > "ham".make-me-a-sandwich; # either an error, or method dispatch
> > }
> >
> > 2.make-ma-a-sandwich; # ordinary method dispatch
> >
> > The primary use case for methodicals is naturally in the setting. Many
> of the
> > methods which are currently defined on lower-level types could become
> > methodicals and they would be available on all values, in any code
> compiled
> > within the Perl 6 setting, without polluting the referencing environments
> of
> > non-Perl 6 code in the same object environment.
> >
> > my method WHAT($thing) { ... }
> >
> > Rakudo already uses something very much like an ad-hoc direct
> implementation of
> > methodicals to handle postcircumfix operators.
> >
> > Methodicals are also useful in user code where the most natural phrasing
> of a
> > calculation is as a property of a system type, for instance from the
> Mandelbrot
> > Advent example:
> >
> > my method mandel(Complex:) {
> > my $z = 0i;
> > for ^$max-iterations {
> > $z = $z * $z + self;
> > return 1 if ($z.abs > 2);
> > }
> > return 0;
> > }
> >
> > Since methodicals do not pollute global referencing environments, and do
> not
> > compromise encapsulation, MONKEY_TYPING is not needed here.
> >
> > A methodical defined inside a class functions much like a private method.
> > There may be something interesting here, but I'm not entirely sure what.
> >
> > There are two natural implementations of methodicals in terms of other
> language
> > features. First, it is possible to treat methodicals as ordinary methods
> > (monkey typing under the hood), but with generated names; the true name
> is
> > bound to the program name only within the correct scope. If possible,
> the
> > methods should be treated as anonymous, accessible only though an opaque
> name
> > object. Care must be taken to prevent incorrect exposure of private
> fields and
> > methods.
> >
> > Alternatively, a methodical can be desugared to a multi sub with the same
> scope
> > as the methodical itself, changing statically named method calls into
> calls to
> > the methodical. This gives reflection invisibility and privacy for free,
> but
> > may require more work to get the multi call semantics exactly right.
> >
> > Thoughts?
> >
> > -Stefan
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAkvOpjcACgkQFBz7OZ2P+dKJ4wCfUpWUDv2/PqYUF1k0hsYaiAns
> > HFAAn2K5SfcJnGq5xk1PIy0QG69LMrwR
> > =uvrz
> > -----END PGP SIGNATURE-----
> >
> >
>
