Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123364
Precedence: bulk
MIME-Version: 1.0
References: <CAPzBOBMpOztgNQx35ZnP4c5ZHV-Ax1ETH0=YMzVT9Hq9cdyyDQ@mail.gmail.com>
 <407efbd0-2d9c-4bcb-b795-0ee326728415@heigl.org> <CAPzBOBPRaxhnjHNzqza57rH1+_j7pb-9FtgB_qf4ONcThHpdAA@mail.gmail.com>
 <b973d444-854b-4978-8d04-531caa16f2a6@heigl.org> <CAPzBOBPn2EpG-mPzA9HFcmC+2qxCD0FGOxAMZc9D_timVCN22Q@mail.gmail.com>
 <defe757c-1bd8-4332-95a3-ee8b158877c3@heigl.org>
In-Reply-To: <defe757c-1bd8-4332-95a3-ee8b158877c3@heigl.org>
Date: Sun, 19 May 2024 11:39:52 +0200
Message-ID: <CAPzBOBOXA+DEeZy65gL8uwA0GA76Nf30bXEbcM-+rFwTLzGjsQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discussion] "Internal" attribute and warning
To: Andreas Heigl <andreas@heigl.org>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Sun, May 19, 2024 at 10:52=E2=80=AFAM Andreas Heigl <andreas@heigl.org> =
wrote:
>
> Hey Robert.
>
> Am 19.05.24 um 09:38 schrieb Robert Landers:
> > On Sat, May 18, 2024 at 9:11=E2=80=AFPM Andreas Heigl <andreas@heigl.or=
g> wrote:
> >>
> >>
> >>
> >> Am 18.05.24 um 19:46 schrieb Robert Landers:
> >>> On Sat, May 18, 2024 at 7:38=E2=80=AFPM Andreas Heigl <andreas@heigl.=
org> wrote:
> >>>>
> >>>> Hey all.
> >>>>
> >>>> Am 18.05.24 um 16:00 schrieb Robert Landers:
> [snip]
> >>> I guess that depends on what you mean by "break the code." Many peopl=
e
> >>> turn warnings into exceptions, and for those people this will
> >>> effectively break their code. Some people may choose to ignore it one
> >>> way or another, but that would be up to them. The idea isn't to break
> >>> people's code though, it's to provide a way to mark very-malleable
> >>> APIs in libraries. Maybe, "Internal" is a bad name for this, but it's
> >>> the most logical.
> >>
> >> The trouble I see is that there are two kind of people: Those that car=
e
> >> about such things and those that don't.
> >>
> >> Those that care about such things will already find these issues durin=
g
> >> static analysis.
> >>
> >> Those that don't care will not turn errors into exceptions but instead
> >> have error-reporting set to 0
> >>
> >> That's why I am hesitant in adding this to the engine but instead woul=
d
> >> love to see this as part of userland maintained static analyzers.
> >>
> [snip]
> > Hey Andreas,
> >
> > I don't think this is a useful way to look at it. Otherwise, what is
> > the point of making any error or warning? Static analysis is useful,
> > but there's a lot of things it misses, especially when dynamic calls
> > start happening.
>
> Probably the most interesting question is about our and the users
> expectation when declaring respectively using an internal entity.
>
> Is it's use something that should just pop up in the logs? And if so:
> What does it mean? Is using an internal entity outside it's expected
> usage actually an error? After all an error should be used when the
> application hits an issue preventing one or more functionalities from
> properly functioning. We can not really say that is happening just
> because someone uses a function in a place we do not expect it to be
> used. It might still work.

Indeed! The issue isn't that it works, it's knowing what to check very
carefully when updating vendored code. It also sets a reasonable
expectation that I can't complain that a maintainer broke something in
my code because I was doing something unsupported.

When it is only used in static analysis, it won't be noticed by people
not using static analysis.

>
> But from the point of view of the person declaring that internal entity
> muich more should happen. The code shouldn't work AT ALL any more.
> Someone is using my code in a way that I did not intend it to be used,
> so the whole application should break.
>
> But we can not assert that.

I disagree with this stance for many principled reasons.

If someone finds a class/method in library code useful, they should be
able to use it. Code reuse is important, and since the library code
could be licensed under the GPL while the main code is MIT or
unlicensed, the developer cannot simply copy the routine into the main
code. Further, they can't simply implement themselves now either,
because they've seen the licensed code.

Another issue I have with this stance is that if there is a major bug
in a library, I should be free to work around the issue by calling
"internal" code to ensure the state doesn't cause a crash in
production.

And yet another issue I have is that as a library author, I don't
really care how people use my code. It's none of my business. If it
works for them, great! I just want to be able to easily communicate
that some code may change unexpectedly between library versions.
Having something like this can be the difference between making huge
refactorings and improvements a patch release or a major release.

Code exists to solve problems, not create new ones and artificial
barriers because of ego.

Having this as part of the engine means that I know it is communicated
even if someone isn't using static analysis.

>
> So by having a look at the expectations of the different parties we can
> calibrate our intentions and then see how we can provide the best solutio=
n.
>
> And to me in that case the best solution would not be to enforce this on
> the language level but to leave it to static analysis. Because I know
> how inventive people can get to use things in ways they are not supposed
> to be used. Search for `composer unfinalize`...

Off-topic, but sharing this just to show my stance on this:

Final is an evil in library code, so I'm not surprised to see people
doing something like that, especially if final classes are used as
arguments to core library functions. It prevents authors from
attaching important metadata to objects, injecting failures during
tests, and ensuring application/business behavior is used -- and no,
composition cannot always solve this problem. I tend to find
alternatives if final gets in my way, or implement an alternative
myself.

>
> Cheers
>
> Andreas
>
>
>
> --
>                                                                ,,,
>                                                               (o o)
> +---------------------------------------------------------ooO-(_)-Ooo-+
> | Andreas Heigl                                                       |
> | mailto:andreas@heigl.org                  N 50=C2=B022'59.5" E 08=C2=B0=
23'58" |
> | https://andreas.heigl.org                                           |
> +---------------------------------------------------------------------+
> | https://hei.gl/appointmentwithandreas                               |
> +---------------------------------------------------------------------+
> | GPG-Key: https://hei.gl/keyandreasheiglorg                          |
> +---------------------------------------------------------------------+