On Aug 26 2024, at 5:57 pm, Bilge <[email protected]> wrote:
> In case it matters, my initial inclination was also to do what some others have suggested, and
> modify the SEND opcodes so that the default is not actually looked up using reflection at all, but
> rather we just send nothing to the function and it can use its default as it would normally, but
> since I had the good sense to ask an engine maintainer how they would approach this problem, they
> cautioned me that this was the approach Stas took 10 years ago
> (https://github.com/php/php-src/compare/master...smalyshev:php-src:skip_params7), that that approach
> was horrendous (paraphrasing) and they would never support something like that (mainly because
> there's like 11 of them and modifying them all would be a complete mess). So whilst you might
> find me quite unmoved by some of the arguments put forth on the mailing list and generally difficult
> to convince, it is not because I am stubborn in my naivete, it is because when wisdom was imparted,
> I listened. I am but a small man standing on the shou
lders of giants.
>
>
The RFC for Stas' implementation of default was very different not only in approach, but it was
put forth at a different time to solve a different problem. I don't think it makes sense to
conflate the two issues. Very importantly Stas was not proposing an expression syntax that increased
visibility and access into function declaration defaults as you are proposing.
https://wiki.php.net/rfc/skipparams
> I am just about to amend the RFC with the major discussion points from detractors, however I am
> still missing a list of even one item that must absolutely be prohibited, along with an explanation
> as to why.
I've seen multiple explanations by many and I know I personally put a code example forth. I am
not sure what prompts you to say that.
I'd be very interested in hearing from you, as the RFC author, specifically about that code
example -- and why you believe the issue I described is worth the cost.
> Indeed, the entire point of the expression grammar is they can be composed freely with one
> another in any way you like; to do otherwise would be radical departure from the intended behaviour.
I think what has been lost in this conversation is that the "detractors" believe the
intended behavior is not a good direction to take the language. It seems to me that we simply
don't think default parameters should be directly accessible to the caller in a major
percentage of the circumstances. Any discussion about expression restrictions or the like has only
happened because those same detractors are offering potential compromise ideas. The fundamental
problem with the RFC to me is that it's creating an access into function declarations that IMO
is neither needed or wise.
Coogle