Tim King <t...@jtimothyking.com> writes: >> "Another difference is that subroutines default to my scope rather >> than our scope. However, subroutine dispatch searches lexical scopes >> outward, and subroutines are also allowed to be postdeclared after >> their use, so you won't notice this much. A subroutine that is not >> declared yet may be called using parentheses around the arguments, >> in the absence of parentheses, the subroutine call is assumed to >> take multiple arguments in the form of a list operator." >> -- http://perlcabal.org/syn/S06.html#Globally_scoped_subroutines > > In other words, the following code will work: > > f(); > my sub f { > g(); > my sub g { > say "It works!" > } > } >
Ah, okay. With the example I get it now. It would be a jarring change from Perl 5 if they didn't look for the sub definition after its use, so that's nice. > Usually, you can't access "my" variables until after their declared. And the > "my" on these sub declarations are superfluous. (So "my sub f" is equivalent > to just "sub f.") But subs are allowed to be used before they're declared, > and subroutine dispatch will search, starting with the innermost lexical > scope, and proceeding outward through broader and broader scopes, until it > gets to the global-most scope. ... > > P6 recognizes a much stronger concept of opaque types. P6 classes have > a private implementation and a publicly accessible API. And as > developer, you can enforce this distinction. So a "my" sub is by > definition part of the private implementation. That's why it feels to > me really silly to mark a "my" sub "is export." I'm not saying that > the language should prohibit you from doing so— I think that every > programmer has a First Amendment right to act like an idiot, because > all geniuses first sounded like idiots. But I'm saying that if subs > are by default in "my" scope, then my best practice (again, speaking > as a developer) should be to declare exportable subs "our." > I see now from your slides I misquoted your example and you did have _is export_ after the sub. That does seem odd. Maybe if it has "is export" after it, a sub should act as if it also had our in front of it instead of the usual default to lexical. But there's also this in S11... "Every compunit has a UNIT package, which gets a lexically scoped EXPORT package automatically. Declarations marked as is export are bound into it, with their tagsets as inner packages. For example, the sub bar above will bind as UNIT::EXPORT::DEFAULT::<&bar>, UNIT::EXPORT::ALL::<&bar>, and UNIT::EXPORT::others::<&bar>." ... and this... "Exports contained within a module will also be bound into an our-scoped EXPORT package nested in the module, again with the tagsets forming inner packages. This is so the import keyword can be used with a package to import from it; the lexical IMPORT package in UNIT, on the other hand, is the only thing that is considered by use for importing." In your example when rakudo sees &Foo::bar in the package with _need_ and fails to find it among Foo's package variables (I want to say "in %Foo" -- is that still how it goes in Perl 6?) seems like it ought to be able to go looking in one of those other places like Foo::EXPORT or Foo::UNIT::EXPORT. _my sub foo_ without the _is export_ ought to be inaccessible, but if you've put _is export_ not so much. It doesn't feel silly or idiotic (I'm not a citizen though, so if this statement is idiotic the bill of rights doesn't help) to me to say _my sub is export_ (and especially not with implied my) if lexicals actually can have their sub references exported by some mechanism. But it seems inconsistent they could be given out if with _use_ but not with _need_. Maybe I've misunderstood something here. -- Mike Small sma...@panix.com _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
