Re: S05 :exhaustive eg
On 4/27/07, Brad Bowman <[EMAIL PROTECTED]> wrote:
I would expect a different ordering. Perhaps the ".*" should be ".*?"
or the output "bracadabr bracad brac br cadabr cad c dabr d br" ?
The :overlap example follows this order.
You're probably right about that:
$ perl5.9.5 -E 'my @m; "abracadabra" ~~ m/ a (.*?) a (?{ push @m, $1
}) (*FAIL) /x; say "@m"'
br brac bracad bracadabr c cad cadabr d dabr br
$ perl5.9.5 -E 'my @m; "abracadabra" ~~ m/ a (.*) a (?{ push @m, $1 })
(*FAIL) /x; say "@m"'
bracadabr bracad brac br cadabr cad c dabr d br
[svn:perl6-synopsis] r14389 - doc/trunk/design/syn
Author: larry
Date: Sat Apr 28 15:23:15 2007
New Revision: 14389
Modified:
doc/trunk/design/syn/S12.pod
Log:
Use of protoobjects for role initial values.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podSat Apr 28 15:23:15 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 27 Apr 2007
+ Last Modified: 28 Apr 2007
Number: 12
- Version: 48
+ Version: 49
=head1 Overview
@@ -1898,17 +1898,32 @@
Dog{ :name }
-This is still lazily evaluated:
+This form is also lazily evaluated:
my $dog = Dog{ :name };
defined $dog or say "doesn't exist"; # Fido doesn't exist
$dog.wag()# Fido wags his tail
-Note that when used as an argument to a method like C, the
-protoobject is sufficiently lazy that autovivifying is done only by
-the appropriate C routine. It does not waste energy creating
-a C object when that object's attributes would later have to be
-copied into the actual object.
+When the typename happens to be a role, autovivifying it involves
+attempting to create a punned class of the same name as the role.
+Whether this succeeds or not depends on whether the role is
+sufficiently complete to serve as a class on its own. Regardless of
+whether such an attempt would succeed, it is always perfectly fine to
+define a lazy protoobject for a role just as long as it's only ever
+used as an argument to C, since C will only be using
+its closure to construct the role's C arguments in the context
+of the complete new class. (Of course, an inconsistent or incomplete
+class composition may subsequently fail, and in fact the incomplete
+role autovivification mentioned above is likely to be implemented by
+failing at the point of class composition.)
+
+Note that when used as an argument to a method like C,
+the protoobject is sufficiently lazy that autovivifying is done
+only by the appropriate C routine. It does not waste energy
+creating a C object when that object's attributes would later
+have to be copied into the actual object. (On top of which, such
+an implementation would make it impossible to use protoobjects to
+initialize incomplete roles.)
The object autovivification syntax works only for literal named types,
so any indirection must be written more explicitly:
S12: can(), signatures and casting
My apologies if these have been answered. I've been chatting with
Jonathan Worthington about some of this and any misconceptions are
mine, not his.
In reading through S12, I see that .can() returns an iterator for the
methods matched. What I'm curious about is this:
if $obj.can('fribble') {
my BadPoet $jibbet = $obj.fribble('repeatedly');
}
Just because $obj.can('fribble') does not mean that the available
fribble(s) will accept a string argument or return BadPoet instances.
In chatting with Jonathan about this, he speculated that I would have
to manually walk the method objects in the iterator to find out if I
really have a suitable method. This seems like what we really have is
$object.might($method). Is there a simpler way of determining if
there's an appropriate method for what I need? It seems like what we
really want is a method object where I can declare a signature and then
do this:
if $obj.can($object_with_signature){ ... }
This raises my second question. What if I have this?
class MadHatter is BadPoet { ... }
If I get back a MadHatter instead of a BadPoet, but I really want the
superclass and not a subclass, how can I enforce that? Do I have to do
something like this? (pseudo-code)
subset ReallyABadPoet where { $^N.type eq "BadPoet" }
my ReallyABadPoet = $obj.fribble('reapetedly');
That seems to fail because the you'd have to invoke every method to
guarantee that you're really getting back the exact type you want. As
such, it seems like we'd need return values to guarantee that the
returned type is exactly what we claimed.
method foo(Int $bar, Int $baz) returns Int {
return $foo/$baz;
}
Since the return value might be a Float, does it get cast to an Int,
thereby discarding information?
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
