develooper Front page | perl.perl5.porters | Postings from June 2006

Re: Its time we set the score straight on Perl 5 and Perl 6 and debunkour own self-generated FUD.

Adam Kennedy
June 20, 2006 01:06
Re: Its time we set the score straight on Perl 5 and Perl 6 and debunkour own self-generated FUD.
Message ID:
>> Frankly, I've seen almost zero reasons for patches needing to be
>> submitted HERE (if I'm understanding your patch rejection claim as being
>> to here to be correct).
> Then you arent looking closely enough, or dont know enough about the
> Win32's API to actually know when such support would benefit things.
> Sorry to put it so harshly but thats my view.

My point is that I, and anyone else, should not HAVE to know the APIs, 
just like I don't know how many other things work.

>> Since Vanilla was created, we've fixed literally dozens of Win32 bugs,
>> and with only one exception (IO::Socket) has there been any need for any
>> involvement from this list.
> Yeah, youve fixed some bugs, ive fixed some bugs, we all fix bugs.
> Considering functionality consider File::Spec still doesnt use the
> Win32 API where it should be doing so, but youve probably never needed
> File::Spec to behave properly. You cant install all modules properly
> on Win32 without Win32API::File, you cant monitor process properly
> without Win32::Process, you cant monitory directory change events
> without Win32::ChangeNotify, you cant write to the eventlog without
> Win32::EventLog. You cant write to the registry without
> Win32API::Registry. Yada yada yada.

As I said, the fixes need to not break existing code. 
File::Spec::Win32's basic functions can be loaded and used even when not 
on a Win32 host, which is useful for various purposes, and code doing 
this is in current use.

Would you break that code to add the feature you want?

As to the rest, none of it necessarily needs to be in the core. 
Win32API::File perhaps for the use of ExtUtils::Install, but little else 
is critical, NOW. What should or should not be in the core is an 
entirely different conversation.

I don't need to look at Win32::Process, I don't need to do change 
notification. If I want to do it, I'll install a module.

This ALREADY works just fine with Win32API::Registry. I need 
File::HomeDir on windows, it needs Win32::TieRegistry, that needs 
Win32API::Registry, they all install, and I continue onwards.

That is no reason to be in the core.

You've asserted that the core should contain some complete minimum set 
of functionality. That is your prerogative as a distribution author 
should you choose to create one, but it's still no reason to be in the core.

>> As for merging Win32 stuff into core, which has been mentioned before as
>> well, I'm still not clear that we have sufficient evidence for it. Such
>> evidence needs to be extremely clear, and not based solely on the
>> opinions and assertions of individuals.
> Its not an opinion when i say these things. They are facts. You cant
> do things you should be able to do with a core perl.
> And frankly I think you should be more receptive of what Win32
> programmers with experience tell you. For two reasons, if you listen
> you might avoid repeating hard lessons they have learned, but much
> more importantly you will be less likely to discourage them from
> participating. There is somethign incredibly frustrating when someone
> without any experience telling you that an opinion you have formed
> over many frustrating hours of hard work is rubbish. Frankly if I have
> to prove things to YOU then im not going to bother and think a lot of
> Win32 people will feel the same.
> OTOH, if somebody posts a suggestion and you dont understand it, a
> positive reception to the post and a requerst for clarification would
> probably go a long way.
>> Again, this is half the reason why Vanilla will be left is pure-core.
> Yes i agree with that objective. However since the objective is to get
> CPAN modules running instead of getting CPAN running properly I think
> youll only get half the job done. You see the problem is that if you
> dont know the API reasonably well you dont even know when something
> could be done better via the API.

These are two entirely different objectives.

First is that Perl works on Win32. Second is that it works better.

I see little point in making significant changes to existing code, when 
currently it doesn't work at all, even if the current implementation is 

It is far far easier to establish proof-of-concept cases to prove one's 
assertions and provide real evidence for one's opinions when you can 
back it up with working code.

As I've said a number of times, when it comes down to wanting a change 
that needs to be made, opinions don't cut it, nor do assertions that 
things are fact.

Ultimately it comes down to code.

>> I think we may be relatively close to enough evidence for perhaps
>> including Win32API::File.
> Id have thought the case would be simple. You cant upgrade Pathtools
> and several other modules without it (under some operating conditions
> anyway). You cant upgrade XS modules that are in use without it. To me
> thats about the end of the story.

Indeed. And while previously we had only words, through your excellent 
efforts, we now have what I think is probably clear enough proof, in the 
form of ExtUtils::Install.

And if you wanted to campaign for the addition of Win32API::File ONLY to 
the core, on the basis that ExtUtils::Install is in the core, then I'd 
be happy to support that.

But the rest, the upgrading of File::Spec, I've yet to see more than 
just assertions. Do you have an URIs etc? Do you have a proof of concept 
module that shows it working we can see?

Adam K Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About