On 4/4/06, David Landgren <[EMAIL PROTECTED]> wrote:
> demerphq wrote:
> There are also some mistakes, like Switch, but once a module goes in, it
> can never be removed. That's the main reason why people are so leery
> these days of adding new stuff to the core, in case they get it wrong.
Thats an argument that carries some weight, and one i havent seen
articulated before.
> > Personally i think the "core is too big" argument is a red-herring
> > given that bandwidth is as cheap as it is these days. Adding a couple
>
> I don't think bandwidth is the argument.
I was under the impression it was.
> > of modules to core would increase the rsynch time by what a second or
> > two? It would suck up a couple of extra K, something like 1% of what
> > most of use for our web-browser cache. So the size argument IMO doesnt
> > hold water.
>
> There is the multiplier effect of having that new K stored on all the
> mirrors to keep in mind.
HD space isnt much more expensive than bandwidth, and we mirror all of
CPAN everywhere so I dont really think its a good argument.
> > Also, there is a tension in the community relating to this issue that
> > i dont think we will see any resolution of soon.
> >
> > Many module authors set a design objective of making their modules
> > "dependent only on core modules". This is a comment that I see on a
> > regular basis.
>
> As long as the core modules are there on the basis that they serve as
> building blocks to build other modules, I don't see any problem with
> that. The trouble is that all the cool tools are evolving so rapidly
> that putting them into core would really cramp their style.
Yes I agree. Building block modules are one thing application like
modules are another.
> > IMO this objecitve is in direct contradiction of the purported P5P
> > objective of not adding stuff to the core and just makes omissions
> > from the core even more critical.
>
> I'm curious, what's critically lacking?
Win32 API support is the one that im focusing on. But id be
sympathetic to similar requirements for other platforms.
> > Anyway, i just wanted to add this because I dont think that you can
> > take it for granted that all perl5porters believe the core module set
> > should be as restricted as possible. I dont. I believe that the core
> > should contain out of the box enough support for the various platforms
> > that perl runs on that when people write code based only on core
> > modules they can do a good job without reinventing wheels or code
> > duplication.
>
> What wheels are being reinvented, or what code is being duplicated? I
> think the core problem-space isn't too bad.
>
> I'm not sure that there are many intermediate level modules left out
> there that can be applied to generic module development. I'm not sure
> that I want to drink the Class::* kool-aid.
All the modules reinventing Win32 workarounds that could be obtained
via exposing internal functionality in Perl, or by allowing access to
the API through a proper Perl/XS layer (like the Win32API modules).
Also, all the code that does stuff like
if (eval "use Win32API::File; 1") { .... } else { #its a broken win32
build, aka "core" }
ends up being a maintenance nightmare.
File::Temp, ExtUtils::Install, File::Spec, are all good example of
modules that could be drammatically improved on Win32 by having access
to the Win32API in core.
> > Long term i think the community needs to sort out this problem because
> > I dont think there is consensus on it, and I think that a lot of
> > people only look at the issue from their own individual point of view.
> > If somebody is concerned about the overall quality of perl and CPAN I
> > think a more holisitic point of view is required.
>
> Who was it who was working on the global CPAN dependency graph, to
> figure out what module was dependent on what? Whatever became of that? I
> think hard numbers that stand on their own merits are about the only way
> to get new stuff into core. Let the early adopters try out non-CPAN
> low-level modules. Then after a while, see what floats to the top.
What do you mean by "hard numbers"?
Im doubtful that any such dependency graph would be helpful with
something like Win32API type stuff. Wheras if the modules were core I
could imaging that a lot of things would end up using them. But thats
the thing, you cant rely on them being there unless you use
ActiveState, and if you are a *nix programmer trying to work around
some UNIX/Win32 cognitive mismatch youll never even know that there
are easy ways to do so, IFF you have access to the API.
So from my point of view providing proper Win32 API access in core is
the way to get _non_ win32 developers to produce robust code on that
OS. I dont expect some developer with no Win32 experience to try to
debug a problem, but if Win32API were in core then at least you could
point them at the POD and say "the solution is there, and its in
core". It means that us Win32 developers could maintain an
abstraction layer in Core so that non-win32 developers could use it
with confidence that a) it will work, and b) it will be available.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
