Hi!
1. SYSTEM NAMESPACES. There are many PHP built-in functions that act on
certain groups of entities. The best examples are the *array_** and
*str* *functions.
There are many of them, and it gets really cumbersome to repeat the same
prefix for each and every one. This is clearly a reminiscence of original
Come on. Is it really that hard to write strlen? Or array_merge? Would
it be better if they were len (of what?) and merge (what?)? I don't
think so.
procedural-style PHP. But now we have namespaces, that were introduced
exactly for this kind of situations. Why not take advantage of it? PHP can
Nope. The namespaces were introduced to manage deep and wide class
hierarchies, especially large frameworks with hundreds of classes, not
to bother little string functions that never hurt anyone.
2. TYPE HINTING. Currently PHP supports argument type hinting for arrays and
objects. As I know, it's also been decided to offer support for this in
function return values. For me it is hard to understand why not offer
Decided by whom? When?
support for type hinting of scalar values as well. Hinting *string*, *int*,
*float* and *bool* values can save a lot of debugging time and would provide
This topic was discussed to death on the list, please read the archives.
If after that you still do not understand what it is about, or have some
comments, please ask then.
code coincides with the global namespace ( \ ) code, I think it's safe to
remove the *define* function and possibly allow the *const *keyword to
define runtime constants as well (when the value is not a constant
expression).
That would not work since code can not be run when class is being
parsed, and after that it is not clear when it is supposed to be run and
in what context, etc. But more importantly - what for? If you need to
calculate something, make it a variable and calculate it in the ctor.
Constants aren't meant to be results of complex calculations, they are
meant to be simple and fixed.
There was a proposal for read-only variables and one for per-variable
getters/setters (actually, with some effort you can do it right now, a
bit less efficiently maybe but doable). This might be direction to go in
this case.
4. PARAMETER ORDER. As noted in an older PHP meeting:
Two letters: BC.
Changing variable order in an existing function is a big fat BC break.
And if we put such a bomb into a new version, what would be the
incentive for people to use it? So that apps would have to be shipped in
2 versions, for the old php and the new php?
These were the major issues that came to my mind until now. I am sure many
things and ideas can be rejected with the reason of backward compatibility
and fear of breaking tons of lines of ancient code. But existing code can
Please remember - what you call "ancient code" other people call
"application on which my paycheck depends". So I think we should be
super-extra-careful when messing with it. That doesn't mean we would
never do any BC-breaking change ever - that does mean there always has
to be a very good reason for it. And I personally don't see
"consistency" being good enough reason. Don't get me wrong - it's good,
it's just not good enough to be valued over working applications.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
