Date: Sun, 17 Jul 2022 14:06:56 -0700
On Sunday, 17 July 2022 11:05:36 PDT Frederick Virchanza Gotham via Std-
Proposals wrote:
> Some of you might be thinking: "Why affirm such subterfuge when the author
> of the library obviously didn't want you messing around in there?", well
> computer programming isn't an exact science. Indeed we have paradigms and
> design patterns, but really at the end of the day we're trying to get
> things done, and this might mean following the instructions from Step 1 to
> Step 9 but then deviating at Step 10.
>
> Being able to manually impose friendship when and where you need it, would
> mean not needing to edit the 3rd party library's header file.
And why don't you want to edit it? You're clearly doing something the library
authors did not want you to do. Your doing of anything with the privates that
you weren't granted friendship with is a clear "voids warranty" step (and if
used in any class in the Standard Library, an automatic "behaviour is
undefined").
Moreover, since you are mucking with internals the authors did not mean for
you to do, you need to be very aware of those internals and how they may
change over time from version to version, vendor to vendor. Therefore, you
must always inspect the headers when you update to know if the members you're
accessing didn't change types, names, or semantics. Since every update is
controlled by you with a fine tooth comb, I don't see why you can't simply re-
add the "friend" line you wanted to impose.
In fact, I'd say that modifying the header is itself a good thing, because it
will force you to think twice before imposing the friendship, and clearly mark
this class as having been altered for your specific purposes. "Voids warranty"
So I agree with you that we just want to get work done, but I don't think we
should have THIS language feature you're proposing. We shouldn't add a hammer
to do unwise things. If you want to get work done, you already can with a hack
and hacks are *meant* to be ugly.
Proposals wrote:
> Some of you might be thinking: "Why affirm such subterfuge when the author
> of the library obviously didn't want you messing around in there?", well
> computer programming isn't an exact science. Indeed we have paradigms and
> design patterns, but really at the end of the day we're trying to get
> things done, and this might mean following the instructions from Step 1 to
> Step 9 but then deviating at Step 10.
>
> Being able to manually impose friendship when and where you need it, would
> mean not needing to edit the 3rd party library's header file.
And why don't you want to edit it? You're clearly doing something the library
authors did not want you to do. Your doing of anything with the privates that
you weren't granted friendship with is a clear "voids warranty" step (and if
used in any class in the Standard Library, an automatic "behaviour is
undefined").
Moreover, since you are mucking with internals the authors did not mean for
you to do, you need to be very aware of those internals and how they may
change over time from version to version, vendor to vendor. Therefore, you
must always inspect the headers when you update to know if the members you're
accessing didn't change types, names, or semantics. Since every update is
controlled by you with a fine tooth comb, I don't see why you can't simply re-
add the "friend" line you wanted to impose.
In fact, I'd say that modifying the header is itself a good thing, because it
will force you to think twice before imposing the friendship, and clearly mark
this class as having been altered for your specific purposes. "Voids warranty"
So I agree with you that we just want to get work done, but I don't think we
should have THIS language feature you're proposing. We shouldn't add a hammer
to do unwise things. If you want to get work done, you already can with a hack
and hacks are *meant* to be ugly.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Received on 2022-07-17 21:06:58