I suggest a little more damage control is needed...
Steph Fox wrote:
Guys and guyess,
...
4. instanceof, is_a(), is_subclass_of(), catch
==============================================
In PHP 5.0, is_a() was deprecated and replaced by the "instanceof" operator.
There were some issues with the initial implementation of "instanceof", which
they way I remember it was that there weren't 'some issues' but that pretty much
everyone but Pierre refused to admit for a very long time that the
instanceof implementation (above all) was useless to the point that a
depreciated
is_a() was often peoples only recourse.
interesting to see the turn around, pity that its seems to have been carried out
so low under the radar - (I followed this subject closely and I can't recall
any decision
being made in the open regarding reversal of position on this subject)
- an occasional "we we're wrong" might not be a bad idea from a marketing
perspective.
relied on __autoload() to search for missing classes. If the class was not
present, "instanceof" would throw a fatal E_ERROR due to the failure of
__autoload() to discover that class. The same behaviour occurred in the
"catch" operator and the is_subclass_of() function, for the same reason.
None of these functions or operators call __autoload() in PHP 5.1, and
the class_exists() workarounds used in code written for PHP 5.0, while
does this mean class_exists() loses its second parameter? or has the default
value changed fom true to false?
either way updates to the docs to reflect the current state would go a long way
to avoiding alot of headaches and confusion (read: 'more irritation').
not problematic in any way, are no longer necessary.
5. Integer values in function parameters
========================================
With the advent of PHP 5.0, a new parameter parsing API was introduced
which is used by a large number of PHP functions. In all versions of
PHP between 5.0 and 5.1, the handling of integer values was very strict
and would reject non-well formed numeric values when a PHP function
expected an integer. These checks have now been relaxed to support
non-well formed numeric strings such as " 123" and "123 ", and will
no longer fail as they did under PHP 5.0. However, to promote code
safety and input validation, PHP functions will now emit an E_NOTICE
when such strings are passed as integers.
another annoyance [for the average phper] in the name of a completely
non-quantified drive to 'promote safety and input validation'.
exactly who benefits from this 'promotion'? and what proof of the benefit
is there? given that there cannot be any proof I would suggest such changes
in warning/notice behaviour belongs within E_STRICT where it's definitely
not going to affect anyone who isn't asking explicitly for it.
6. Abstract private methods
===========================
Abstract private methods were supported between PHP 5.0.0 and PHP 5.0.4,
but were then disallowed on the grounds that the behaviours of 'private'
and 'abstract' are mutually exclusive.
if one thinks they are mutually exclusive then one can not use them...
but I don't see the reason to change the actually behaviour. a moving target is
worse than an imperfect one, I would have preferred it if this had been left
alone,
the only harm it was doing was by offending someone's idea of aesthetics and/or
correctness - given that even when 99.9% of a given group agree on something
that something
does not equate to THE TRUTH it seems to me counter productive to impose
the views on those that don't share them (and may possibly have code that
relied on the current behaviour).
7. Access modifiers in interfaces
=================================
Under PHP 5.0, function declarations in interfaces were treated in exactly
the same way as function declarations in classes. This has not been the case
I really like to be given a solid technical reason why that had to be changed,
even a 'we required X, but we couldn't implement X because of Y so we removed
the capability to Z which made X possible' rather than 'your not allowed to
do it anymore because we think you are wrong'.
since [Oct 13th 2004], at which point only the 'public' access modifier was
allowed in interface function declarations. Since [April 26th 2005], the
'static' modifier has also been allowed.
WTF - static is allowed on interface methods??? to quote some of the comments
made to me by Wez on the subject (he, Andi and others have said the same thing
many times):
"interfaces technically only apply to objects, so no static calls make
sense in an interface context."
and:
"An interface is a public contract that describes the behaviour of an
object.
If you're not using interfaces in that way, you're doing something
fundamentally wrong."
so basically what we seem to have is that 'static' is allowed on interface
methods
but its 'fundamentally wrong' AND 'protected'/'private' are not allowed on
interfaces
because they are 'fundamentally wrong' - that is not consistent (and personally
I'd like
back the ability to be 'fundamentally wrong' in all cases not just some), and
it becomes
very irritating when the behaviour of interfaces keeps changes with every new
version
(major or minor).
regardless on what the current implementation does/allows it might be worth
getting everyone on one line regarding what it _should_ do before making more
[academic] changes.
However, the 'protected' and 'private'
modifiers will now throw an E_ERROR, as will 'abstract'. Note that this change
should not affect your existing code, as none of these modifiers makes sense
in the context of interfaces anyway.
that sounds arrogant. fundamentally speaking the 'does not make sense' argument
is a matter of consensus regardless of any argumentation used to back it up. in
ten years
time a totally new/hot/popular development paradigm could contradict this
completely -
who is to say what is right and wrong?
PS - Wez' notion of 'fundamentally wrong' is ridiculous. the concept of 'wrong'
is dualistic, dualism exists by way of division - for which there must be
something to
divide - ergo dualism is not fundamental, as a result 'fundamentally wrong' is a
contradiction in terms. given that he intends on taking over the world I can
understand the premature attempt to force his views upon others ;-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
