David Green writes:
> >So making it "go in the core" may just mean that it's
> >on the list of recommended modules to install.
>
> Does that mean having to "use Some::Module" to use it?
Not necessarily. Glop, on which I'm doing a presentation at OSCON (have
to plug it sometime ;-), makes use of an idiom where you don't have to
'use' everything you want. That's because the small module quanta used
in the design would make the first 50 lines of your program 'use'
statements.
I should expect a similar thing in Perl 6 if traits are going to be
packaged up in their own modules.
> If so, that partially defeats the point of having a magical DWIMy
> shorthand in the first place. (And if not -- then I guess it's
> irrelevant to most end users whether it's "really" a module or not.)
Here's one defining feature of core:
if $feature.has_shorthand {
$feature.in_core = !$feature.requires_use;
}
Sorry. Got tired of English.
> I think stringified filehandles should be "core" -- i.e. always
> available without having to install ...
There's a lot of stuff like that. Way too much to include in a
distribution. That's why we're going to distribute close to nothing
with Perl 6 in order to force vendors to install a decent module suite.
It's likely that CPAN will have a Bundle::EYEWTIBWATA. [1]
> In fact, my general attitude towards random feature $foo is: useful
> to lots of people who want to use it + not harmful to people who
> don't = put it all in the core.
And there's our second system syndrome. Fortunately, Perl is embracing
its second system syndrome.
I think with a sensible auto-inclusion system (really, they're quite
nice--if it can be done at compile time), we'll be able to keep things
out of core and still make them feel like they're in core. There's
something to be said for modules like that.
Luke
[1] Everything You Ever Wanted To Install But Were Afraid To Ask
