Re: use fatal err fail
On 29/09/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> * "try { foo() } err next" will next even if foo() did not throw
> an exception, but returned undef. But I don't think that's a problem
> in most cases. One can always do:
> try { foo(); 1 }
I think that's a flag that it's not a great idea.
For the example given, I'd rather write
my $fh = try {open $_; CATCH {next} };
and still fit it on 1 line!
For what it's worth, I'd like to chime in on 'yes please' for having
fatals on by default.
I've been hanging round some perl forums lately, and it's such a
basic, recurrent issue.
Cheers,
Carl
Re: my $key is sensitive;
Brent, Why not post the original query to p6compiler for their take on it? Carl
Re: new sigil
Where did you get ALT-155 from? I've just checked the windows Character Map, and ¢ (cent) is ALT-0162 ( If it's not in your startmenu, do start -> run -> charmap ) It displays in Eclipse (3.1.1) whether the Text File Encoding is set to Cp1252 (default) or UTF-8 or ISO-8859-1 Cheers, Carl
Re: new sigil
On 21/10/05, Steve Peters <[EMAIL PROTECTED]> wrote: > On Fri, Oct 21, 2005 at 09:42:00AM +0100, Carl Franks wrote: > > Where did you get ALT-155 from? > > > > I've just checked the windows Character Map, and ¢ (cent) is ALT-0162 > > ( If it's not in your startmenu, do start -> run -> charmap ) > > Actually, both work. That's where the issus with the documentation starts. Strange, in any windows app on my machine, ALT-155 prints "o" with a diagonal line through it (bottom left to upper right). cent: ¢ not: ø I wonder if it's a font issue? Carl
default values for attributive parameters
Are default values supported for attributive parameters in an argument list?
I wish to convert these 2 subroutines to perl6:
sub foo {
my $self = shift;
$self->{foo} = defined $_[0] ? shift : undef;
}
sub bar {
my $self = shift;
$self->{bar} = defined $_[0] ? shift : $DEFAULT;
}
Is this correct?
method foo (?$.foo = undef) {};
method bar (?$.bar = $DEFAULT) {};
Thanks,
Carl
pass hash to sub expecting named params?
Will it be valid to pass a hash to a subroutine expecting named
params, if the hash keys match the names?
sub do_this (+$foo, +$bar) {
# whatever
}
%arg = (
:foo,
:bar,
);
do_this(*%arg);
I use this technique a lot, and it would be unfortunate to miss out on
the advantages of subroutine signatures and have to 'go back' to the
perl5-ish
sub do_this (*%args) { }
Carl Franks
Re: pass hash to sub expecting named params?
That puts my mind at ease!
Many thanks,
Carl
On 4/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Carl Franks writes:
> > Will it be valid to pass a hash to a subroutine expecting named
> > params, if the hash keys match the names?
> >
> > sub do_this (+$foo, +$bar) {
> > # whatever
> > }
> >
> > %arg = (
> > :foo,
> > :bar,
> > );
> >
> > do_this(*%arg);
>
> Yep, and that's exactly how you do it, too. I believe that the * is
> unnecessary (but still acceptable) if you're already in the named zone:
>
> do_this(foo => 1, %arg); # ok
>
> Luke
>
Re: Nested captures
Are you subscribed to perl6-compiler?
Yesterday Patrick Michaud posted "PGE features update (corrections)"
which describes the results you've got:
* Match objects for nested captures are nested into the surrounding
capture object. Thus, given
rulesub = p6rule(":w (let) ( (\w+) \:= (\S+) )")
match = rulesub("let foo := 123")
the outer match object contains two match objects ($/[0] and $/[1]),
and the second of these contains two match objects at
$/[1][0] and $/[1][1].
print match# outputs "let foo := 123"
$P0 = match[0] # first subcapture ($1)
print $P0 # outputs "let"
$P0 = match[1] # second subcapture ($2)
$P1 = $P0[0] # first nested capture ($2[0])
print $P1 # outputs "foo"
$P1 = $P0[1] # second nested capture ($2[1])
print $P1 # outputs "123"
Cheers,
Carl
Re: ./method
On 5/19/05, Martin Kuehl <[EMAIL PROTECTED]> wrote: > I have tried, but I can't make myself like it. I'm afraid I have to agree. When I saw it used in code after this discussion (I think it must have been somewhere in pugs t/ or ext/) my reaction was "yuck". (for what it's worth) Carl
hash slice from array items
Is [EMAIL PROTECTED] the correct way to get a hash slice using elements of an array? (it's giving me a compilation error with pugs) Cheers, Carl
Re: hash slice from array items
On 5/25/05, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > Works just fine for me. What version of pugs are you using? Perhaps > you need to upgrade. Ok, I've just realised I had missed a '->' to '.' in my perl5 to perl6 conversion, I was trying to do [EMAIL PROTECTED] = $obj->list; I wasn't sure if slicing from an array was implemented, as I couldn't find any pugs tests for it. Thanks for your help, Carl
construction clarification
I have a class that normally takes a list of named arguments.
I also want to be able to handle a single argument.
class Foo {
multi method new (Class $class: Str $date) {
return $class.bless(date => $date);
}
submethod BUILD ($.date, $.time, $.offset) {
# some error checking here
}
}
my $foo = Foo.new('2005-05-30');
#
Is this the correct way to handle my scenario?
My explicit 'new' method should only handle the case of
a single argument - otherwise the 'new' method
inherited from Class will handle a list of named
arguments.
My explicit BUILD submethod is called, regardless
of which 'new' method is called, correct?
Cheers,
Carl
Re: construction clarification
> It's *a* correct way. But redundant in this particular case.
> The universal new() would handle the one-argument call exactly the same
> as your overloaded new() does. Presumably, however, the one-argument variant
> would do something else as well.
Some people will need to call the constructor with a whole host of options:
my $foo = Foo.new(
date => '2005-06-01',
other => 1,
params => 1);
For the typical case though, rather than forcing people to have to write
my $foo = Foo.new(
date => '2005-06-01);
they should be able to write
my $foo = Foo.new('2005-06-01');
However, if I allowed the default 'new' to handle that case, then the
BUILD submethod has to be aware of that.
I thought it would be cleaner to 'document' the special case with a
seperate constructor, and also not require any special-case logic in the
BUILD submethod.
Is that really off the wall?
Carl
Re: construction clarification
> The universal new() would handle the one-argument call exactly the > same as your overloaded new() does. Is that correct? S12 says... All classes inherit a default new constructor from Object. It expects all arguments to be named parameters initializing attributes of the same name. ... which seems to contradict. Carl
Re: proposal: binding with a function
> : alias newlines, newline; Isn't it possible to add a Role to the relevant Class, which specifies that is 'handles' the method name you want as an alias? Carl
Re: When can I take given as read?
> sub factorial (Int $n is topic) {
> return 1 when 0;
> return $n * factorial $n;
> }
hmm, could we write...
sub foo (Class $self is topic: +$foo, +$bar) {
.method;
}
to avoid having to use ./
?
Cheers,
Carl
