Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20216
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4381E7BF.9060908@iamjochem.com>
Date: Mon, 21 Nov 2005 16:29:03 +0100
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Steph Fox <steph@zend.com>
Cc: internals <internals@lists.php.net>
References: <017401c5ed14$6dc59000$e0acbc3e@foxbox>
In-Reply-To: <017401c5ed14$6dc59000$e0acbc3e@foxbox>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Upgrade notes for PHP 5.1 - final draft
From: jochem@iamjochem.com (Jochem Maas)

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 ;-)