4 ms·

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

by trebor 10y ago

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.

ajmurmann 10y ago
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.
adimitrov 10y ago
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.
- ryanlm 10y ago
  They emitted oplines to the opcode array directly from the parse production.

by trebor 10y ago

ajmurmann 10y ago

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.

adimitrov 10y ago

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.

ryanlm 10y ago
They emitted oplines to the opcode array directly from the parse production.