Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re^2: Factory Pattern in Perl6

by hardburn (Abbot)
on May 18, 2016 at 00:32 UTC ( #1163280=note: print w/replies, xml ) Need Help??

in reply to Re: Factory Pattern in Perl6
in thread Factory Pattern in Perl6

Thanks for your reply. I had to set this project aside for a little while, but I was able to return to it tonight and whittle down the actual problem.

After some playing around, the reason turned out to be the specific object being tested having a BUILDALL. Commenting out the BUILDALL method allowed the object to be constructed in the right class.

To narrow it down from there, the BUILDALL started by calling callsame, as discussed in Changing that to nextsame (as shown in allowed the object to be constructed as expected.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Replies are listed 'Best First'.
Re^3: Factory Pattern in Perl6
by raiph (Chaplain) on May 18, 2016 at 05:17 UTC
    If commenting out a custom BUILDALL fixes things then, almost certainly, the custom BUILDALL has a bug. If you share it I'll see if I can spot a bug.

    nextsame means about the same as callsame; return (but I think the compiler avoids the additional callframe on the stack), i.e. call the next multi candidate (with the exact same arguments) and don't bother running any more of the code that follows the nextsame.

    I would expect a multi method that starts with a nextsame to behave as if the method didn't exist, i.e. exactly the same as just commenting the method out. So your s/callsame/nextsame/ unfortunately doesn't narrow things down.

      I put the full code up here: It's demonstrated by doing:

      $ perl6 -I lib t/010_packet_ack.t 1..7 Type check failed for return value; expected Game::Tetrachromat::Packe +t but got Any (Any) in method read_packet at /home/tmurray/proj/Game-Tetrachromat/lib/Ga +me/Tetrachromat/PacketFactory.pm6 (Game::Tetrachromat::PacketFactory) + line 79 in block <unit> at t/010_packet_ack.t line 33 # Looks like you planned 7 tests, but ran 0

      The factory is in lib/Game/Tetrachromat/PacketFactory.pm6, and the class it's supposed to be using for this test is lib/Game/Tetrachromat/Packet/Ack.pm6. All packet types do the role lib/Game/Tetrachromat/Packet.pm6.

      I was able to work around things by converting Game::Tetrachromat::Packet to a class instead of a role, and using BUILDALL for Packet::Ack. Inheritance is arguably the right way to go for this particular case, so I'll probably just leave it that way. Still, if there's a bug in perl6, I figured it was worth putting up the code that breaks it.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        Thanks for the code. Fwiw I found it very readable.

        Mu's BUILDALL returns the constructed object (per the self line at the end). I imagine a custom BUILDALL needs to do the same thing.

        If you have the patience I'd appreciate you confirming that adding a trailing self line to Ack's BUILDALL fixes the problem you first posted about. (If so I'll update my original response to make it clear my guess about public attributes was a red herring.)

        It's a mystery to me why converting a role to a class helped.

        To wrap up I'll try to explain the error you just quoted. I'll go in to far more detail than I imagine you need in the hope it's helpful to someone some day.

        I would appreciate confirmation that this error now makes sense to you as follows:

        1. Ack's BUILDALL returns Nil

          A block of code in Perl 6 is interpreted as a semilist (semicolon separated list) of statements. When a block is evaluated it returns the value of its last statement unless the code explicitly specifies otherwise. In this case the last statement is a for loop:

          unit class Game::Tetrachromat::Packet::Ack; # FTFY :) ... method BUILDALL(|) { ... for ... { ... } }

          A loop construct as the last statement is evaluated in sink context. Sink context means any value returned by an expression or statement gets thrown away -- down the sink as it were.

          Perl 6 uses Nil to communicate nothingness. So Ack's BUILDALL attempts to return Nil.

          Because Ack's BUILDALL's signature doesn't constrain what it returns, returning a Nil is fine and doesn't trigger a type error.

          The code continues to run...

        2. The Nil becomes an Any

          When a Scalar container is empty it pretends it contains a value, by default, an undefined Any. So if Nil gets assigned to any Scalar container with the default default the effect is indistinguishable from assigning it an undefined Any.

          Somewhere between the return of Ack's BUILDALL and the completion of the PacketFactory read_buffer method code my $packet = $ the Nil becomes an Any. The my $packet declaration doesn't specify a type constraint. So the assignment of an Any (or a Nil which becomes an Any) proceeds without a type error.

          The code continues to run...

        3. return $packet triggers a type error

          Rakudo finally gets around to reporting a type error at line 79 of PacketFactory because the enclosing method, read_buffer, defines a return type in its signature: returns Game::Tetrachromat::Packet but $packet contains an Any.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1163280]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (9)
As of 2019-10-16 12:24 GMT
Find Nodes?
    Voting Booth?