.index($substr).defined
is now called .contains($substr)
. With that, the entire loop body becomes just
.say if .contains($string) && .words[1] != $*PID
]]>
.index
now returns an Index value, which is just like an Int except it is only false when it is undefined. So you can just say
.say if .index($string) && .words[1] != $*PID
]]>
Maybe what I wanted is some way to get notified if my Travis-CI configuration is not using the latest stable so I can manually add it.
]]>I wouldn't want to see WebFramework::RouteBased::Mojolicious, for instance.
]]>In Perl 5, the module names are unique identifiers and, to a large extent, the descriptive, searcheable name of a thing.
In Perl 6, the ambiguity among multiple 'Chess' modules is resolved with the :auth adverb and tags
key in the META file addresses the issues about finding modules you raise.
In fact, I'd argue that your post is suggesting we repeat Perl 5's mistakes and release modules with wordy names to rectify the problems that no longer exist.
]]>I'm not too bothered about it being a decentralized project. I can see the merits in growing the Perl6 namespace organically to find out what works and then doing some retrospective cataloguing to fix problems. The tags give you that extra dimension so that your hierarchy can be shallow and allow easy code migration, but adds a bit of "need-to-know" tricks to get the right module when you'd ideally want to just use HTTP;
with the caveat that it will bite you in the ass someday. Perhaps to solve that perennial problem with CPAN of module proliferation, the top level namespace default becomes reserved for the 5* modules that gain the community's approval or we add in an "official" tag, peut-etre
use Mail:approved-by('LWALL')
It does mean that upon coming into the light, darkpan code will need to add in auth tags that were previously not needed. I think it's very Perlish to want it and have it both ways. Certainly Mojolicious, Dancer and Catalyst have all carved out respectable places for themselves and "everybody knows" what they are, but long module names are certainly a feature inside Mojolicious for the sake of clarity which is what we strive for in code.
Maybe it passes the newbie test because I intuitively "got" the idea of tags that you all mentioned, but trying to find out about them was tricky. They are not in the Perl6 docs (it would have been Too Much Information there), but I found something helpful in Jonathan Stowe's github repo. I think I'm hampered by not knowing enough to ask the right questions and not having time to participate in the conversations where these things are discussed. Can't wait for the Bug book to come out.
So, I don't know where I would have run across the :auth tag if I hadn't spouted off which, to me, is a part of the process. It certainly passes the test of "make the hard things possible", but I'd like to be convinced that it "makes the easy things easy". Maybe a little bit of boilerplate upfront is worth the payoff in the end.
]]>but trying to find out about them was tricky
It's documented in the S22 speculation, I believe: http://design.perl6.org/S22.html#META6.json
use Mail:approved-by('LWALL')
That's not at all what I was talking about. The distribution's META file has a tags field that let any "distribution accumulators" (such as a CPAN site) to use those tags when trying to figure out what the user wants to find. Just like the posts on this website can be tagged with say, 'Perl 6' tag, and then searching for 'Perl 6' would bring up such articles.
So, I don't know where I would have run across the :auth tag if I hadn't spouted off which, to me, is a part of the process.
I don't think there's yet any decent support for the :auth adverb.
I'd like to be convinced that it "makes the easy things easy".
I won't be one to do that. IMO, the :auth adverb is no different ::Foo in module name. If you don't specify it explicitly, you leave an ambiguity in your code. I'm yet to learn how such an ambiguity is resolved and what its implications are. And so far, I'm of a negative opinion of using :auth as a way out of requiring unique distribution names, even if :auth addresses the concerns you brought up in the original post.
]]>sub foo($foo) { ... }
multi sub foo(Int $int) { say 'int' }
multi sub foo(Str $str) { say 'str' }
First is normal subroutine. This is dynamic language feature.
Last two are function overloading. This is static language feature.
I think this is messy for user because dynamic features and static feature are mixed.
My proposal is that how about separating dynamic feature and static feature in Perl 5.
package Foo;
sub foo ($foo) { ... }
package Bar : static;
sub foo(Int $int) { say 'int' }
sub foo(Str $str) { say 'str' }
Function overloading is indeed a static language feature.
But the multi
keyword doesn't provide static function overloading.
The multi
keyword provides dynamic multiple dispatch.
Function overloading occurs at compile-time, when the compiler looks at the static types of the declared arguments to an overloaded subroutine or method and selects which overloading to call on the basis of those compile-time types.
Multiple dispatch occurs at run-time, when the interpreter looks at the dynamic types of the actual arguments to a multisub or multimethod, and selects which variant to call on the basis of those run-time types.
(I originally explained the important difference between the two concepts in one of the original Perl 6 Exegesis documents.)
So the multi
keyword is a perfectly appropriate addition to dynamic languages like Perl 6, and maybe even eventually to Perl 5.
Indeed, you can use multiple dispatch now in Perl 5 via the Class::Multimethods::Pure
or Kavorka
CPAN modules, and soon via the (next release of) the Dios
module as well.
Thanks for your comment.
But the multi keyword doesn't provide static function overloading. The multi keyword provides dynamic multiple dispatch.
I think is is not good because performance cost occur when type check is done at run-time,
and it increase launguage complexity.
Perl has already complex syntax. I don't hope more complexity.
For example, I like cpan-minus than cpan-plus. why? cpan-minus is fast, minimal and enough.
I like small aproach which can solve problems smart.
For the long time, Perl is complained for the dirty and complex syntax.
We should recognize more perl complexity is more week point of Perl language.
So the multi keyword is a perfectly appropriate addition to dynamic languages like Perl 6, and maybe even eventually to Perl 5.
I strongly oppose the mix of dynamic features and static features in one space.
It mix the week point of dynamic language and the week point of static language.
It don't mix the good point of dynamic language and the good point of static lanuage.
It is slow and complex things.
It is not simple and fast things.
My proposal is that "how about implementing real static features in static package?".
package Foo : static;
static package is optimised for performance, less memory, and parallelization.
Perl can call the method of static package.
golang is good example.
golang has many syntax limitaion.(not exception, not inheritance, not generics).
but the limitation is good for performance, compile speed, less memory, and parallelization.
I think Perl need the question "What limitation is good for us?".