Front page | perl.perl5.porters |
Postings from August 2016
Re: Internals:: undocumented
Thread Previous
|
Thread Next
From:
demerphq
Date:
August 15, 2016 11:11
Subject:
Re: Internals:: undocumented
Message ID:
CANgJU+WB2GHAE7GKbrS3W9VY92s+zO4QHBQyi_AbEesu0cw+Ew@mail.gmail.com
On 15 August 2016 at 13:02, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
> * demerphq <demerphq@gmail.com> [2016-08-15 10:24]:
>> On 14 August 2016 at 23:12, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
>> > It seems to have about a dozen actual callers on CPAN:
>> > http://grep.cpan.me/?q=-file%3Appport.h+hv_clear_placeholders
>>
>> One of them is me in DDS. They all follow the same pattern. Someone
>> read the code to Hash::Util and then unrolled what it does to lock
>> keys.
>>
>> Personally I am disinclined to be sympathetic to this type of
>> violation of abstraction layers.
>
> So am I!
>
> But what didn’t happen is me reading the entire code to DDS, spotting
> that you had done this, and deciding that because you were calling
> private APIs, I wouldn’t use your module. :-)
>
> Should I have? Would you take the position that DDS breaking on me is
> fair because as a user I should have examined it closely enough to
> understand everything it does – including all of the guts knowledge
> necessary to judge that?
Well I think you would be well justified getting mad at me for doing
it. Also I would consider it my responsibility to fix, not yours to
work around. I hope the other authors would behave the same.
> Of course the abstraction violation should be cleaned up. My argument is
> just about choosing an ordering of steps in such a way that people who
> trusted their upstream won’t bear the punishment for (all of) upstream’s
> bad choices.
>
> Should they not trust their upstream? Part of the reason I trusted DDS,
> without reading the entirety of its code, was because you wrote it, and
> I knew who you are. Was I in error? Will you issue a mea culpa to all
> your users for your poor judgement now? :-)
Well, yes. :-)
Mea-culpa. I shouldnt have done that. I will fix in time for it to not
be a problem. :-)
>
> Now to be frank, I don’t truly care about assignment of blame – I ask
> these questions as an argument about a general attitude, not because
> I consider it a terribly productive concern on a case by case basis in
> individual breakages. I’m more interested in moving forward from where
> we are, whatever the reason we got there, and how to do so with minimal
> collateral damage.
>
> But one question that *would* be interesting to ponder here is… why did
> *you* do that, then? :-) Didn’t you know better?
I definitely /should/ have known better. I honestly dont recall why i
did it. Probably excessive chumminess with the implementation of
Hash::Util affecting my good judgement.
(Unlike most, I wrote a chunk of HU, and know what it does and how it works.)
>> hv_clear_placeholders is an internals API call. Having two wrappers,
>> one in Hash::Util and the other in Internals is not a big deal IMO.
>
> True.
>
> Although one reason I could imagine that people used Internals:: was to
> avoid having to load another module (however reasonable a call that is),
> in which case being able to say “it’s going to load Hash::Util anyway”
> might help persuade them to switch. I’m just guessing at this, though.
Oh! Thats an interesting angle I didn't consider. I suppose I could
convert the Internals.pod to Internals.pm and put the required logic
there. But that would require people to load Internals, which might be
even worse...
Ill mull on this one and think about it. FWIW, i was thinking if I do
put it back in Internals ill make it warn on use.
>> I honestly think that people should just use the functions in
>> Hash::Util directly and not use hv_clear_placeholders at all.
>
> I don’t disagree at all. I just don’t want already-written code which
> calls it to break all of a sudden.
Yeah, as unsympathetic as I am I also dont want to break code
unnecessarily. Its just frustrating how difficult it can be to clean
this stuff up. Sigh.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next