Skip Menu |
Report information
Id: 130378
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: dabe [at] dabe.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: "our sub Long::Package::name {...}" Doesn't DWIM
To: rakudobug [...] perl.org
Date: Mon, 19 Dec 2016 19:22:12 -0500
From: "Dabrien 'Dabe' Murphy" <dabe [...] dabe.com>
Vis-a-vis the following:  http://dabe.com/misc/perl6-class_method.html

## Foo.pm
  class Foo::Bar { has $.var }
       $Foo::var  = 42;

package Foo { our sub x { say "X" } }
       &Foo::y =  sub   { say "Y" };
our sub Foo::z          { say "Z" }
## foo.p6
#!/usr/bin/env perl6

use lib $*PROGRAM.resolve.dirname;
use Foo;

Foo::Bar.new;     # OK
say $Foo::var;    # OK: 42

Foo::x;           # OK: X
Foo::y;           # OK: Y
Foo::z;           ## X::AdHoc.new(payload => "Could not find symbol '\&z'")

There was some discussion on #perl6 about
whether the compiler should disallow such long names [psch++], or whether it should stuff it in a package and vivify it for you [jnthn++].

IMHO, as a typical perl5 switcher, jnthn's solution seems the most DWIM-ish — and since the other alternatives offer just as much "spooky action at a distance", it seems surprising that "our sub Long::Package::name" wouldn't have the same effect.

Just my 2¢...  :-D


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org