Re: Upgrade notes for PHP 5.1 - final draft

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 ;-)