On 26 August 2024 05:44:44 BST, Mike Schinkel <m...@newclarity.net> wrote:
>> On Aug 25, 2024, at 12:21 PM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk>
>> wrote:
>> The Reflection API is a bit like the Advanced Settings panel in a piece of
>> software, it comes with a big "Proceed with Caution" warning. You only move
>> something from that Advanced Settings panel to the main UI when it's going
>> to be commonly used, and generally safe to use. I don't think allowing
>> arbitrary operations on a value that's declared as the default of some other
>> function passes that test.
>
>You analogy is faulty. You are conflating a complex API — Reflection — with
>one use-case of that API which — per the RFC — has well-defined syntax and
>semantics and purely due to its simplicity is more likely to be used than the
>Reflection API and far less likely to be used incorrectly than the Reflection
>API.
You are misunderstanding the analogy. The analogy is that the Reflection API as
a whole is like the Advanced Settings page, with its big "Proceed with Caution"
sign. Accessing the default value of someone else's function is like a setting
which you can only currently access on that advanced setting screen, but people
are proposing we move to a big tempting tickbox on the main UI.
I was responding to someone justifying anything and everything the proposal
allows, because Reflection already allows it. If the feature was "first class
syntax to access private methods of a class", I don't think it would be
controversial to challenge it. Saying "Reflection can already do it" would be a
poor defence, because part of Reflection's job is to break the normal rules of
the language.
>> On Aug 25, 2024, at 11:31 AM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk>
>> wrote:
>Can you give a specific example from code we are likely to find in a
>production application — vs. a forum debate — where someone is likely to use
>`default+1` AND where it would be problematic for the author?
The overriding rule, in my head, is that the caller shouldn't need to know, and
shouldn't be able to find out, what a particular implementation has chosen as
the default. So the particularly problematic operations are things like this:
foo($whatWasTheDefault=default)
foo(logAndReturn(default))
foo(doSomethingUnrelated(default) && false?: default)
I can see people inventing use cases for these as soon as they're available,
but by doing so they will be completely changing the meaning of default
parameters, which currently mean "I trust the implementation to substitute
something valid here, and have no interest in what it is".
Note that under inheritance, the default value may even change type:
class A { public function foo(int $bar=42) { ... } }
class B extends A { public function foo(int|string $bar='hello') { ... } }
Perhaps that would be more obvious if the declaration happened to look like
this:
function foo(optional int $bar) {
default for $bar is 42;
// ...
}
As far as I can see, nobody has actually justified reading values out in this
way, only said it's a side-effect of the current implementation.
You ask how a library can provide access to that default, and the answer is
generally pretty trivial: define a public constant, and refer to it in the
parameter definition. I sometimes do that with private constants anyway, just
to make the value more easily documented, or use it in a couple of different
contexts.
The only exception I think is "new in initializer", where you would have to
provide a function/method instead of a constant, and couldn't currently reuse
it in the actual signature.
Aside: one of those examples brings up an interesting question: is the value
pulled out by "default" calculated only once, or each time it's mentioned? In
other words, would this create 3 pointers to the same object, or 3 different
objects?
foo(array|Something $x=new Something);
foo([default, default, default]);
Rowan Tommins
[IMSoP]
