On Thu Feb 18 18:38:20 2016, lloyd.fo...@gmail.com wrote: > When a package already exists in an outer scope, any package declared > will > insert itself into it even if it's meant to be lexically scoped. This > includes the SETTING(s) (the most outer scopes). It is also > problematic for > our scoped things which manage to transcend the compunit interface's > encapsulation of their globalish symbols. > > This leads to a number of problems and inconsistencies. I believe it > will > be even more relevant when we try and implement jnthn++'s versioning > design: > > https://6guts.wordpress.com/2016/02/09/a-few-words-on-perl-6- > versioning-and-compatibility/ > > Some examples: > > ## 1 leak out of lexical scope > { > my module Cool::Utils { } > } > say Cool::Utils; > > ## 2 runtime symbol refers to something different to compile time > symbol > with same name > sub leaked-into { > my class Cool::Utils { method doit { "one" } } > say Cool::Utils.doit; #->one > say ::("Cool::Utils").doit; #->two > } > > { > my class Cool::Utils { method doit { "two" } } > leaked-into(); > } > > ## 3 our scoped packages are not available for introspecting in > CompUnit::Handle.globalish-package; > > # lib/Cool/Utils.pm > class Cool::Utils {} > class Foo { }; > > # main.pl > my $cu = > $*REPO.need(CompUnit::DependencySpecification.new(:short- > name("Cool::Utils")); > say $cu.handle.globalish-package.WHO.keys; #-> (Foo) > > # This was one of the things I didn't consider ( and isn't tested in > require.t -- will do now) which caused problems with my patch. > # see https://github.com/rakudo/rakudo/pull/714 ugexe's comment. > > ------------ > > Another problem with our scoped packages inserting themselves into the > setting is that when we have multiple settings which one of them does > it > insert it into? > > What if a module like IO::Socket::SSL has 'use v6.c', so it never sees > the > 6.d setting. Then someone does: > > use v6.d; > use IO::Socket::SSL; > > If the 6.c-IO::Socket.WHO === 6.d-IO::Socket.WHO everything will be > fine, > but if not IO::Socket::SSL won't be visible to the 6.d code. It could > copy > itself to all the settings but that seems ugly to me. > > The solution could be to create a special type of package used for > declaring sub-packages of packages that already exist in an outer > scope > which could search it's own .WHO for the symbol before delegating to > the > outer scope package's WHO.
Not all the original code still compiles; can you revisit the request with new examples showing the issue? -- Will "Coke" Coleda
