> On Feb 24, 2021, at 11:49 AM, Chase Peeler <chasepeeler@gmail.com> wrote:
>
>
>
> On Wed, Feb 24, 2021 at 11:35 AM Mike Schinkel <mike@newclarity.net <mailto:mike@newclarity.net>> wrote:
>
>> On Feb 24, 2021, at 11:27 AM, Chase Peeler <chasepeeler@gmail.com <mailto:chasepeeler@gmail.com>> wrote:
>>
>> On Tue, Feb 23, 2021 at 11:27 PM Mike Schinkel <mike@newclarity.net <mailto:mike@newclarity.net>> wrote:
>> > On Feb 23, 2021, at 2:05 PM, Rowan Tommins <rowan.collins@gmail.com <mailto:rowan.collins@gmail.com>> wrote:
>> >
>> > On 23/02/2021 18:41, Albert Casademont wrote:
>> >> Sure, it's not a big deal having to write the ": null" but it
>> >> doesn't add
>> >> any value
>> >
>> >
>> > On the contrary, it adds an important piece of information: that the default value is
>> > "null", rather than "false", or "0", or "new EmptyValue()".
>> > For instance, it doesn't seem at all obvious to me that this code should produce
>> > a null:
>> >
>> > $items = [];
>> > $itemCount = $items ? count($items);
>> >
>> > I might be more convinced that "null" is the "natural" value if
>> > the left-hand operand was only checked against null, not "falsiness": in that case, you
>> > can read it as "if it's null, leave it alone". I'd still be inclined towards
>> > "too specific to use up more syntax", though.
>>
>> If you look at it from a software engineering perspective — which is how I assume most on
>> this thread have been looking at it — being more explicit in the code is probably a better
>> practice than saving a few keystrokes.
>>
>> OTOH, if you view it from the perspective of a *templating* language — which is what PHP
>> was initially created to be, for the web — then the reduction in visual noise from omitting
>> ": null" would be a nice plus. And in the case of templating, the distinction between null
>> vs. false vs. "" would be completely moot.
>>
>>
>> But PHP isn't just a templating language anymore.
>
> It is not? If it is not I think a lot of userland PHP developers never got that decree.
>
>
> I didn't say it COULDN'T be used for templating
It would benefit when PHP *is* used for templating which is still not an insignificant use of PHP,
and this one simple thing would make templates easier to read.
> (although even then I'd suggest utilizing a library like smarty or twig)
A long time ago I read an article on SitePoint that argued that using templating languages like
Smarty or Twig made no sense because PHP *is* a templating language.
That stuck with me and for many (most?) use-cases I still agree with it.
> but that it is a lot more than that. I'd also say that, good or bad, the direction of the
> language in the last 15+ years has been to make it a robust language that can be used for more than
> just templating.
I think it is specious to imply allowing $foo ? $bar to return null when $foo==nil would make PHP a
less robust language.
> Well it's pretty obvious. If php currently supported a statement like "$user ?
> 'online'" then a change that requires the third argument would break every single
> instance of code that didn't have one and wouldn't provide any functional gains as nothing
> prevents people from adding on the ": null" if they want to. It's a moot point,
> though, because PHP doesn't support it. I just included that statement to give context to my
> views - that I'm not automatically in favor of changes just because they enforce better
> development practices.
So 1.) if PHP allowed "$user ? 'online'" and then 2.) PHP later disallowed it
then 3.) the second action would created BC concerns?
Yes, that is a moot point with respect to the proposal posed by this thread.
-Mike