That's lifetime of the object, which is still monkeytyping, just on a less
global level than modifying the class directly.
Compare the Ruby example to this: (syntax is entirely made up):
my $foo = SomeClass.new;
{
methodical bar(SomeClass) { say "Hello, world!" }
$foo.bar # "Hello, world!"
}
$foo.bar # Error, undefined method bar. Or reverts to SomeClass's bar if it
exists.
But doesn't Perl 6 already have this with lexical multimethods ("my multi")
?
On Wed, Apr 21, 2010 at 10:11 AM, John Harrison <ash....@gmail.com> wrote:
> 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-----
> > >
> > >
> >
>
--
Mark J. Reed <markjr...@gmail.com>
