Subroutine parameter with trait and default.

[Michael G Schwern]

I'm pondering what the proper syntax is for a subroutine parameter with both a
trait and a default.  That is...

sub foo ($arg = 42)

and

sub foo ($arg is readonly)

together in one parameter.  Would that be

sub foo ($arg = 42 is readonly)

or

sub foo ($arg is readonly = 42)

The first looks ambiguous, what if the trait is meant to apply to the default?
The second looks downright wrong.


PS  Incidentally, it seems silly to have "is rw" but not "is ro".  I keep
writing "is ro".


-- 
package Outer::Space;  use Test::More tests => 9;

Are keys, values, kv, pairs, etc. named unaries?

[Patrick R. Michaud]

According to the test suite (t/spec/S29-array/kv.t), the .kv
method is defined on arrays to produce an interleaved list
of indices and values:

my @array = ;
say @array.kv.perl; # [ 0, "a", 1, "b", 2, "c", 3, "d" ]

The kv.t file also shows a functional form of kv():

my @array = ;
say kv(@array).perl;# [ 0, "a", 1, "b", 2, "c", 3, "d" ]

Is the C function (keys, values, pairs, etc.) a named unary?  
I.e., what is the result of... ?

my @array = ;
my @b = kv @array, ;
say @b.perl;

Pm

Re: Should $.foo attributes without "is rw" be writable from within the class

[Daniel Ruoso]

Sex, 2008-09-19 às 10:25 -0700, Jon Lang escreveu:
> Daniel Ruoso wrote:
> > In SMOP, it is handled based on the package of the Class, the private
> > storage inside the object is something like
> >   $obj.^!private_storage<$!bar>
> > and
> >   $ojb.^!private_storage<$!bar>
> Note that this ought only be true of class inheritance; with role
> composition, there should only be one $!bar in the class, no matter
> how many roles define it.

er... what does that mean exactly?

   role B {
   has $!a;
   }

   role C {
   has $!a;
   }

   class A does B, C {
   method foo() {
  say $!a;
   }
   }

I think in this case $!B::a and $!C::a won't ever be visible, while the
reference to $!a in class A will be a compile time error.

OTOH...

   role B {
   has $.a;
   }

   role C {
   has $.a;
   }

   class A does B, C {
   method foo() {
  say $.a;
   }
   method bar() {
  say $!a;
   }
   }

In that case, both B and C declare a *method* "a" which happens to be
visible in class A (and probably a composition error), but $!a in method
bar is still a compile time error, because there's no $!a declared in
class A.

Or does that mean that

class A does B, C {...}

actually makes the declarations in B and C as if it were declared in the
class A?

daniel