On Mar 04 2007, Smylers wrote:
> for @invoice
> {
> .process;
> } or fail 'No invoices to process';
If that actually works then I'm happy.
--
Rick Delaney
[EMAIL PROTECTED]
kit.
[% FOREACH records %]
[% whatever %]
[% ELSE %]
Search returned no records.
[% END %]
--
Rick Delaney
[EMAIL PROTECTED]
ed states.
Presumably you will be able to make warnings fatal as in Perl 5 so you
should be able to get the behaviour you want, too.
--
Rick Delaney
[EMAIL PROTECTED]
iguity. An error here
would just be confusing.
Now, for those who want .abc to call $?SELF.abc within the given block
then I think it would be clearer if they spelled out that intention with
something like
given $y { use dot '$?SELF'; # or just 'use dot' with suitable default
when 1 { .abc } # calls $?SELF.abc
}
--
Rick Delaney
[EMAIL PROTECTED]
emented as such.
>
> pugs> map { ref $_ } split /(..)*/, 1234567890
> (::Str, ::Array::Const)
Sorry if I'm getting ahead of the implementation but if it is returning
$0 then shouldn't ref($0) return ::Rule::Result or somesuch? It would
just look like an ::Array::Const if you treat it as such.
--
Rick Delaney
[EMAIL PROTECTED]
t; >
> > sub bar() {
> > "def" ~~ /^(.)/; # $1 now "d"
> > foo();
> > say $1;# Outputs "d"
> > }
> >
> > bar();
> >
> > # Correct (I hope so)?
>
> Yeah, they're lexical, just like in Perl 5.
Not just like Perl 5, I hope. If it was then the above would print
"d".
--
Rick Delaney
[EMAIL PROTECTED]
or it. It also clearly
distinguishes the field type for two-character fields. Neither of these
is a strong argument for changing the existing design but I'm wondering
why the first table above would be easier to learn/remember than the
second.
--
Rick Delaney
[EMAIL PROTECTED]
even close:
method FETCH ($var, $index) {
my $val = $var[$index];
return $val unless $val.can("STORE");
my $x is very_read_only := $val;
return $x;
}
And how the trait connects to the FETCH-replacing I don't even know
where to begin.
--
Rick Delaney
[EMAIL PROTECTED]
undef_to(0).
There is no default here, only a rule saying what assignment of undef
stores. Accessing an uninitialized element should raise an exception,
not give zero.
In the case where people want assigning undef to set the default (i.e.
treat undef the same as uninitialized) then they would set both
properties to the same value.
my int @a is default(1) is undef_to(1);
--
Rick Delaney
[EMAIL PROTECTED]
given, and no spam warning issued). This sort of logic deferral is
> common to many uses of undefined values (or "NULL") in databases, even
> when columns have defaults that are non-null.
The reference to databases is salient. There are surely many examples
to be found in SQL books.
--
Rick Delaney
[EMAIL PROTECTED]
The overload technique can be made considerably less ponderous by
creating one class that behaves as your proposal. Then those that like
it could just
use RFC93 sub {
$_[1] ? $fh->pushback($_[0]) : $fh->getn($_[0])
};
my $scalar = RFC93->new;
$scalar =~ /pat/;
--
Rick Delaney
[EMAIL PROTECTED]
11 matches
Mail list logo
