> On Feb 24, 2021, at 11:49 AM, Chase Peeler <chasepee...@gmail.com> wrote: > > > > On Wed, Feb 24, 2021 at 11:35 AM Mike Schinkel <m...@newclarity.net > <mailto:m...@newclarity.net>> wrote: > >> On Feb 24, 2021, at 11:27 AM, Chase Peeler <chasepee...@gmail.com >> <mailto:chasepee...@gmail.com>> wrote: >> >> On Tue, Feb 23, 2021 at 11:27 PM Mike Schinkel <m...@newclarity.net >> <mailto:m...@newclarity.net>> wrote: >> > On Feb 23, 2021, at 2:05 PM, Rowan Tommins <rowan.coll...@gmail.com >> > <mailto:rowan.coll...@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
