Hacker News Reader

Comment by trebor | Hacker News Reader

I disagree. Namespaces help hugely, as do Traits, etc. It used to be difficult back in the pre 5.4 days, but we have come a long way since then.

Older projects will suffer till they're brought up to spec, true.

View on HN

I don't think what you say really invalidates his point though. Namespaces and traits might help a lot, but that still doesn't make them used wide spread or introduced them to the overwhelming amount of terrible legacy code bases that have no namespaces and untested functions that are hundreds of lines long. You can write bad code in any language, but PHP used to be a much worse language and many developers got socialized with that. When you are leaning PHP it's easy to pick up bad habits because the code base tut are using is likely full of them. You are likely to look at code examples using old versions of PHP that don't teach you good practices. That of course doesn't mean you can't error awesome code in PHP it just means it's easy to write bad code.

In which ways do Traits of all things help write good, disciplined code bases?

I think traits, and their Java equivalent, are OK to touch up legacy APIs (as they did with the Java collections API) but I have found no good place to stick them in a new project.

Not to say PHP hasn't been introducing functionality for writing good, stable code bases (type hinting in function signatures, namespaces, better garbage collection, an actual AST — as an aside: how ON EARTH did they do without an AST pre-PHP7?) but traits don't strike me as the feature to think of when designing a new code base.

They're not extendable, they're not overridable, they're monolithic, and classes expose their implementation details to them, which makes traits super fragile.

They emitted oplines to the opcode array directly from the parse production.

Reply on news.ycombinator.com