Re: Setting private attributes during object build
On 2 February 2012 17:40, Damian Conway dam...@conway.org wrote: I sounds like I simply misunderstood yary's problem, but I'd be very glad to be reassured that's the case. :-) AIUI, yary is talking about the default BUILD submethod that is generated if you don't provide your own (or maybe its the behaviour of BUILDALL when it can't find a BUILD submethod) which sets any public attributes from corresponding named arguments, but doesn't set private atrributes.
Operator precedence fiddling
sub infix:foo ($a, $b = ($a foo 2 * 3 - $a)) is tighter(infix:*)
{
$a == 0 ?? 1 foo 2 * 3 !! $a + $b
}
say 1 foo (2 * 3);
# 7
say (1 foo 2) * 3;
# 9
say 1 foo 2 * 3;
# 9
say infix:foo(1);
# Niecza: 7
say 0 foo 0;
# Niecza: 9
The way that Niecza does this is to install the operator with default precedence
before the signature (which means the default is parsed with * binding
tighter than
foo) and then twiddling the precedence before the body (which means the $a == 0
case is parsed with foo binding tighter than *)
Is this right?
Is it necessary (i.e. does the spec mandate the operator existing
while parsing the
signature and/or body)?
I'm considering doing the work to get Rakudo to do the tighter/looser
traits and can't
find the bits of the spec which might apply to these (admittedly
bizarre) edge cases.
I suppose for completeness I should have added in some more traits
which used foo
in an expression - or is that definitely not ok?
exponentiation of Duration's
A recent rakudo commit [1] is a quick fix for #78896 [2] to allow exponentiation of Duration's. I'm uneasy with allowing this and I think the spec probably meant not to but is badly worded [3]: Durations allow additive operations with other durations, and allow any numeric operation with a number as the other argument: $duration * $duration# WRONG, durations aren't geometric $duration * 2# ok, a duration twice as long 2 * $duration# same What are your thoughts? [1] https://github.com/rakudo/rakudo/commit/d9e22463479927fa8f1f594753979022de35970d [2] http://rt.perl.org/rt3/Ticket/Display.html?id=78896 [3] https://github.com/perl6/specs/commit/32abb95b9776e1cb7672c8a6a77612c86b37aea2#L0R1333
Re: S04 - forbidden coding-style
On 7/22/06, Aaron Crane [EMAIL PROTECTED] wrote: Larry Wall writes: Maybe we should just make statement modifiers uppercase and burn out everyone's eye sockets. :) ... Bearing that in mind, would the eye-socket-burning return $foo IF $something; really be so bad? This has really started to grow on me. I like this idea even if we don't change the rules for end of statement after curlies.
