Front page | perl.perl5.porters |
Postings from August 2010
Re: [PATCH] Support B::Generate and B::C
Thread Previous
|
Thread Next
From:
Reini Urban
Date:
August 29, 2010 07:53
Subject:
Re: [PATCH] Support B::Generate and B::C
Message ID:
AANLkTimS0zQ-eSA8jQ5YtBKc_YemjgL+St1+qw0mX1xL@mail.gmail.com
2010/8/29 Nicholas Clark <nick@ccl4.org>:
> On Sun, Aug 29, 2010 at 12:10:56PM +0200, Reini Urban wrote:
>> The only way out seems to through away those modules, or to have a plan
>> for 5.14 to support them again.
>> It makes me sick to rewrite most parts of core just because someone went
>> berserk and enforces the believe it should not be used outside core
>
> I am *not* berserk. I did not *go* berserk.
>
> Your choice of words continues to be extremely undiplomatic.
>
> I repeat, I repeat:
I would rather consider deprecating whole B undiplomatic.
The only remaining goodies in B which work are Concise and Lint.
> 1: At the time, I unpacked the current indexed version of CPAN, and checked
> which non-API functions were used by modules. I only made static those
> which were unused by indexed versions. I was quite methodical about this.
>
> Yes, I realise now, that this was not as comprehensive as I perhaps could have
> been, as I didn't check all unindexed distributions.
On my first cry you said my fault, not yours.
Please my understand also my situation. I took long abandoned modules,
ported it successfully to the new 5.10 refactoring and than after several
years I have to find out that those modules use functions which they
should not have, according to some strict perl policy.
Going "berserk" is enforcing a policy which should never have been that strict,
simply because it makes technically and API wise no sense to forbid usage
of actually used functions.
I cried then, nothing happened, now we have two major versions 5.10 and 5.12
which cannot be supported if we go into the strict policy mode.
This happened with S_ and then when someone added
PERL_DL_NONLAZY=1 to the tests all tests using B::Generate fail now.
>> I will not rewrite pad_alloc, cv_clone, he's and hek's, ... and keep
>> maintaining that mess. This is not the idea of libraries.
>> Those modules used these functions from the very beginning.
>
> 2: I have no objection to functions being added to the API with documentation,
> and (some) tests for that documented behaviour
I didn't add them to the public API. They are X, not A.
Nobody else should use them, but they can be used.if needed.
That's my understanding of X.
> You patch has no tests.
I'm not qualified enough to write such tests for core functions.
I just need the exports.
We never had global sym tests, otherwise we would have detected
breakage earlier.
> For the documentation for fold_constants I see:
>
> -static OP *
> -S_fold_constants(pTHX_ register OP *o)
> +/*
> +=for apidoc Xpd|OP*|fold_constants|NN OP *o
> +
> +Fold constants under this op. This is run after constructing
> +UNOPs and BINOPs and in the ck_select check routines.
> +See L<perlguts/"Compile pass 1a: constant folding">.
> +
> +=cut
> +*/
> +OP *
> +Perl_fold_constants(pTHX_ register OP *o)
>
> So does that mean that it's valid in future for this function to stick to
> *that* documentation, and only fold constants?
>
> As I discovered by accident last night, it also
>
> b: creates targets for ops that need targets but don't yet have them
>
> and I see from looking at the code it also
>
> c: propagates scalar context for ops that return a scalar
> d: runs LINKLIST()
> e: implements 'use integer';
>
>
> As it's not documented as doing any of those, is it OK for a future version of
> perl to stop doing those? (Which might happen as a side effect of refactoring)
This documentation of such X non-APIs should give potential core hackers
some ideas. If actual core hackers know it better than they should document it.
I'm for sure no core hacker, I just have to deal with them.
And I bet there is a silent mass which supports my point and disagrees
with your policy.
I can also make it simple as you, and just declare those modules
and all dependent modules broken and unsupported since 5.10,
and will refuse all patches which re-implement half of core. This point is near.
I even had to write a small pad_alloc for Windows.
--
Reini Urban
Thread Previous
|
Thread Next