Anonymous classes
Hello,
I'm having a seriously good time porting Maypole to Perl 6. If you
still have reservations about how Perl 6 is going to be to program in,
I urge you to try programming in it.
Now, commercial over, I have some questions.
What's the syntax for declaring inherited anonymous classes, and
then adding methods to them?
I've realised that anonymous classes are an excellent solution to
subclassing *related* classes - for instance, you have a Foo class which
creates Foo::Request and Foo::Response objects, and when you subclass
Foo, you may want to specialise things in Foo::Request and Foo::Response
as well. So instead you go:
class Foo {
has Class $.request_class is rw;
method BUILD {
$.request_class = class is Foo::Request; # Or whatever
}
}
And then you have a request class that is a singleton class to each
Foo instantiation, which can be specialized however your particular
Foo subclass needs.
--
Almost any animal is capable learning a stimulus/response association,
given enough repetition.
Experimental observation suggests that this isn't true if double-clicking
is involved. - Lionel, Malcolm Ray, asr.
Re: Anonymous classes
Hi,
Simon Cozens wrote:
I'm having a seriously good time porting Maypole to Perl 6. If you
still have reservations about how Perl 6 is going to be to program in,
I urge you to try programming in it.
Now, commercial over, I have some questions.
:)
class Foo {
has Class $.request_class is rw;
method BUILD {
$.request_class = class is Foo::Request; # Or whatever
I think the only thing you're missing are two braces:
$.request_class = class is Foo::Request {};
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: function signatures?
Hi,
Yuval Kogman wrote:
We have a pretty complex declarative language for argument
processing in the parameter declaration:
[...]
arity as a number does not give enough reflection into these
properties.
Indeed.
Are signatures going to be an exposed first class object in Perl 6?
I hope so, too.
~foo.signature;
# Signature objects should stringify to a canonized form, e.g.:
# ~sub (Str $bar, CoolClass $z where {...}) {...}.signature ==
# 'Str $bar, ANONCLASS(0xDEADBEEF)'
# (BTW, I don't think it's possible to display anonymous subtypes more
# friendly, as the where-clause may contain arbitrary code, and Code
# objects are not (yet?) fully introspectable -- i.e.
# foo.statements[3].line doesn't work.)
+foo.signature.required_args;
# Number of required args
foo.signature.required_args;
# Hash name - class
foo.signature.positional_args;
foo.signature.named_args;
# etc.
Thoughts?
--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon!|
Fully introspectable Code objects?
Hi,
while responding to nothingmuch++'s post function signatures?, I
thought that it'll be great if Code objects were fully introspectable.
I.e.:
foo.statements; # List of statements
foo.statements[0] # First statement
foo.statements[2] = ...;# Statement modification?
And all objects returned from the introspection methods should stringify
appropriately, so that...
say ~sub { 42 + $^a }; # prints
sub ($a) { return 42 + $a; }
Is this going too far?
Is this wanted?
Is it useful?
(At least readonly access would be nice, as allowing writes to
foo.statements will make compiler optimisations much
harder/impossible.)
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: Anonymous classes
[EMAIL PROTECTED] (Ingo Blechschmidt) writes:
I think the only thing you're missing are two braces:
$.request_class = class is Foo::Request {};
Thank you; then how do I put methods into $.request_class?
--
I will make no bargains with terrorist hardware.
-- Peter da Silva
Re: Anonymous classes
Hi,
Simon Cozens wrote:
[EMAIL PROTECTED] (Ingo Blechschmidt) writes:
I think the only thing you're missing are two braces:
$.request_class = class is Foo::Request {};
Thank you; then how do I put methods into $.request_class?
$.request_class = class is Foo::Request {
method blarb (...) {...}
...;
};
# or:
$.request_class = class is Foo::Request {};
...;
# later (mixin of an anonymous role):
$.request_class does role {
method blarb (...) {...}
...;
};
--Ingo
--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon!|
Re: comprehensive list of perl6 rule tokens
On May 26, Patrick R. Michaud said: commit N backtracking fails completely cut N remove what matched up to this point from the string after P N we must be after the pattern P !after PN we must NOT be after the pattern P before PN we must be before the pattern P !before P N we must NOT be before the pattern P As with ':words', etc., I'm not sure that these qualify as tokens when parsing the regex -- the tokens are actually or ! and I'm curious if commit and cut capture anything. They don't start with '?', so following the guidelines, it would appear they capture, but that doesn't make sense. Should they be written as ?commit and ?cut, or is the fact that they capture silently ignored because they're not consuming anything? Same thing with null and prior. And with after P and before P. It should be assumed that !after P doesn't capture because it can only capture if P matches, in which case !after P fails. So, what's the deal? -- Jeff japhy Pinyan % How can we ever be the sold short or RPI Acacia Brother #734 % the cheated, we who for every service http://japhy.perlmonk.org/ % have long ago been overpaid? http://www.perlmonks.org/ %-- Meister Eckhart
Re: Fully introspectable Code objects?
On 5/29/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Hi,
while responding to nothingmuch++'s post function signatures?, I
thought that it'll be great if Code objects were fully introspectable.
I.e.:
foo.statements; # List of statements
foo.statements[0] # First statement
foo.statements[2] = ...;# Statement modification?
And all objects returned from the introspection methods should stringify
appropriately, so that...
say ~sub { 42 + $^a }; # prints
sub ($a) { return 42 + $a; }
Is this going too far?
Is this wanted?
Is it useful?
I think it would be useful. It's one of those features that less than
1% of people will ever use, but will allow the implementation of a
module that 99% of people use.
However, You can't really access it statement by statement and make it
useful. You have to track scope enters and exits to keep track of
names, and you have to look inside the statements to see what they're
doing. And it may be impossible to find statement boundaries from
pure bytecode.
A better way to do this would be to save parse trees along with the
code object. One may not want to do this, however (for instance, for
code obfuscatory purposes, or for plain old memory footprint), so we
should enable it by some pragma:
use save_parse_trees;
And then we can use the eventually existing parse tree introspection
interface that we already know.
Luke
Re: function signatures?
Ingo Blechschmidt wrote:
Are signatures going to be an exposed first class object in Perl 6?
I hope so, too.
~foo.signature;
# Signature objects should stringify to a canonized form, e.g.:
# ~sub (Str $bar, CoolClass $z where {...}) {...}.signature ==
# 'Str $bar, ANONCLASS(0xDEADBEEF)'
# (BTW, I don't think it's possible to display anonymous subtypes more
# friendly, as the where-clause may contain arbitrary code, and Code
# objects are not (yet?) fully introspectable -- i.e.
# foo.statements[3].line doesn't work.)
+foo.signature.required_args;
# Number of required args
foo.signature.required_args;
# Hash name - class
foo.signature.positional_args;
foo.signature.named_args;
# etc.
Thoughts?
Translations of the corresponding Pugs types into Perl 6 code is at:
ext/Perl-MetaModel/lib/Pugs/VCode.pm
However they are mostly still sketches. If you have specific ideas about
the Code::Signature signature in Pure Perl terms, place it in;
ext/Perl-MetaModel/lib/Code/Signature.pm
These objects will eventually be what you get from foo.meta, etc. Or at
least I assume that the way to get to the object's signature will be .meta.
Maybe the Code class will define a .signature method as an alternative
to .meta.signature.
Sam.
