Why doesn't PHP remove the horrid $ symbol for variables and the -> symbol for calling methods? I think those alone would do a lot more for its perception and adoption than adding the pipe operator.

▲

phatskat 8 days ago | parent | next [-]

I actually don’t mind them, and I’ve been out of daily PHP work for a few years now. When I see people denote internal variables with _ or elements with $ in JS, it rubs me the wrong way, but in PHP the $ is kind of nice.

I also prefer the look of ->, it’s _cool_

▲

kijin 8 days ago | parent [-]

Other languages have all sorts of oversized arrows, like ==> and >>>.

-> in PHP and C++ looks clean by comparison.

I'll never forgive them for the brain fart they made of the namespace separator, though.

▲

esskay 8 days ago | parent | next [-]

What would the alternative for a namespace separator be? The backslashes work well with PSR-4 to give a logical visual of the expected directory structure.

▲

account42 7 days ago | parent [-]

Since PHP takes a lot of syntax from C-like languages, the C++ namespace separator :: would be the obvious choice. Not sure if this conflicted with something in PHP though.

	▲	jimktrains2 7 days ago \| parent [-]
		https://www.php.net/manual/en/language.oop5.paamayim-nekudot... scope resolution operator

▲

LeonM 8 days ago | parent | prev [-]

> I'll never forgive them for the brain fart they made of the namespace separator, though.

You mean the backslash? What's wrong with that?

	▲	kijin 7 days ago \| parent \| next [-]
		The backslash is universally reserved as an escape character. It was decided almost 20 years ago so I'm totally used to it and there's no point arguing about it anymore. But the decision to reuse the backslash as a namespace separator still causes inconvenience from time to time. For example, when you write PSR-4 configuration in composer.json, all the backslashes need to be doubled, including (and especially!) the trailing backslash.
	▲	account42 7 days ago \| parent \| prev [-]
		To someone not already familiar with PHP it looks like you are trying to escape something.

▲

jeroenhd 8 days ago | parent | prev | next [-]

Same reason C doesn't introduce classes and C++ doesn't remove pointers: it's a) part of the core language and b) extremely inconsequential for any serious developer.

I actually like the clarity these dollar signs add in a code base. Makes it easier to recognise (dynamic) functions, and makes it harder to accidentally shadow methods.

Other languages will let you do `const Math = {}` and nuke the entire math library, or write stuff like `int fopen = 0;` to make the fopen method call inaccessible in that scope. With PHP, you don't need to restrict your variable name to "something that hopefully won't conflict with an obscure method".

The -> is a leftover from an older programming language that I'd rather have replaced by a ., but not at the cost of breaking existing code (which it surely would).

▲

asddubs 7 days ago | parent | next [-]

I do also appreciate that php has an explicit string concat operator rather than overloading +. Though of course it could just use another symbol for that to get rid of -> if we're talking about time travel. As it stands, you can't really do $obj.method(), because method() could be a function returning a string as well, so it's ambiguous

▲

account42 7 days ago | parent | prev [-]

> The -> is a leftover from an older programming language that I'd rather have replaced by a ., but not at the cost of breaking existing code (which it surely would).

Isn't it because . was already used for string concatenation in PHP. I mean the -> syntax wasn't invented by PHP but it didn't just inherit it without thought either.

	▲	int_19h 7 days ago \| parent [-]
		Indeed. And the reason why PHP used . for string concatenation is because Perl did.

▲

nolok 7 days ago | parent | prev | next [-]

Because back compat' is a very strong feature of the language, same reason "match" was created instead of replacing switch.

As a result, taking a php 5.2 script and moving it up to 8.5 is super easy, and taking a PHP 4 one is barely harder only longer (since it probably uses the horrors that were register_globals and co).

Ultimately, I prefer this than a fragmented ecosystem impossible to resolve.

▲

throw_m239339 8 days ago | parent | prev | next [-]

> Why doesn't PHP remove the horrid $ symbol for variables and the -> symbol for calling methods? I think those alone would do a lot more for its perception and adoption than adding the pipe operator.

Because it simply can't do that in a retro-compatible way. -> isn't so bad, C/C++ uses that as well. as for $ I guess it came from Perl. The point is already used for string concatenation, where other languages would overload the + operator.

▲

ahofmann 8 days ago | parent | prev | next [-]

I honestly don't understand this. The syntax is one of the most boring parts of a programming language. It is solved by the IDE (and now LLMs). I don't care about syntax, I care about what I can build. Since the beginning of time people argue about things like tabs vs. spaces, or the dollar sign and I honestly don't understand why that is. It just doesn't matter.

Just to be clear: consistency does very much matter. The mental load of reading totally different styles of code is awful and a waste of energy.

	▲	Timwi 7 days ago \| parent [-]
		Readability (and hence, maintainability) is definitely a factor in decisions like this. In the particular case of the pipe operator though, the article does mention something it lets you do that you couldn't do before: in a context where only an expression is allowed (such as match), you can now do things that previously would not have worked because it would have required temporary variables.

▲

pkkm 7 days ago | parent | prev | next [-]

PHP has its significant flaws, but superficial syntactic differences aren't among them. In my experience, it takes two weeks to get used to pretty much any syntax.

▲

guskel 7 days ago | parent | prev [-]

The $ symbol gave me RSI as a dev just starting out. I will never forgive PHP for that. Such an unergonomic syntax.