Re: [PHP-DEV] Class constructor behaviour
Am 17.01.2015 um 15:02 schrieb Dan Ackroyd: > class constructors PHP does not have class constructors (static method automatically invoked when a class is initialized). It only supports object constructors (method automatically invoked when an object is created). > Several classes in PHP return null when there is a problem in the > parameters passed to their constructor e.g. > > [...] > > Several constructors check the parameters that they are given.and > then just give a warning when they are not acceptable. e.g. > > [...] > > Some constructors check the parameters they are given, and then emit > either a 'Catchable fatal error' error or other error e.g. Classes implemented in C / provided by PHP must not have any of the above issues. +1 for fixing them. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PEAR and make install on master
Hi, so, the removal of deprecated features has started and make install is now rightfully failing because PEAR is installed by default, although it is not compatible anymore: Installing PEAR environment: /home/atlassian/phpNext/lib/php/ Fatal error: Non-static method PEAR_Installer_Role::initializeConfig() cannot be called statically, assuming $this from incompatible context in phar:///.../pear/install-pear-nozlib.phar/PEAR/Config.php on line 599 make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 I've tried to look up the pear MLs, but I haven't seen any recent activity... what's the plan, if any? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class constructor behaviour
Hi, On 18/01/2015 09:31, Sebastian Bergmann wrote: Several classes in PHP return null when there is a problem in the parameters passed to their constructor e.g. [...] Several constructors check the parameters that they are given.and then just give a warning when they are not acceptable. e.g. [...] Some constructors check the parameters they are given, and then emit either a 'Catchable fatal error' error or other error e.g. Classes implemented in C / provided by PHP must not have any of the above issues. +1 for fixing them. +1 here as well. Sounds like material for a new RFC. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PEAR and make install on master
Am 18.01.2015 um 09:40 schrieb Matteo Beccati: > what's the plan, if any? Remove it? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Remove deprecated functionality in PHP 7
On Sun, Jan 18, 2015 at 3:08 AM, Yasuo Ohgaki wrote: > Hi Nikita, > > On Sat, Jan 17, 2015 at 2:16 AM, Nikita Popov > wrote: > >> All items of this RFC have been accepted for removal in PHP 7. >> >> I'll land the minor removals sometime soon; the unbundling of ext/ereg and >> ext/mysql should probably be done by someone else who's more into the PECL >> business. >> > > iconv.input_encoding, iconv.output_encoding, iconv.internal_encoding, > mbstring.http_input, mbstring.http_output and mbstring.internal_encoding > (since PHP 5.6; use php.input_encoding, php.internal_encoding and > php.output_encoding instead) [TODO] > > I may handle this if you would like. > That would be appreciated! When dropping the ini settings, please make sure that it's still possible to use Zend multibyte. If I remember correctly, right now Zend multibyte can only be used with the deprecated mbstring.internal_encoding setting, but not using php.internal_encoding. Thanks, Nikita
Re: [PHP-DEV] Class constructor behaviour
"Andrea Faulds" wrote in message news:23490588-0131-4b0f-a7aa-c9c8c7666...@ajf.me... Hi François, On 17 Jan 2015, at 15:37, François Laupretre wrote: I would prefer deciding that returning null is the standard way for a constructor to inform the PHP core that the object creation failed (for any reason). This would be trapped by the core and cause a catchable fatal error. This is more compatible with the 'exception-less' behavior of the core in general. The constructor is still free to throw an exception but this wouldn't be encouraged nor the standard way to inform the core that an error occurred. I don’t really agree here. For some reason we have this tradition of not using exceptions for “procedural” stuff. That sort of makes sense for functions, but classes are “OOP” and therefore I don’t see a good reason why they shouldn’t throw exceptions. You are forgetting one minor thing - an object may be instantiated from a piece of procedural code. In fact the very first object can only be instantiated from procedural code. The idea that every piece of code that uses "new" will have to be amended to be in a try...catch block is a huge amount of work that does not solve any problem (except to satisfy the delicate sensibilities of the OO purists). Exceptions and OOP (and namespaces, even) should not be the domain of userland exclusively, they are also the domain of internals/core. If you really hate exceptions, I’d say you should just use one of those ridiculous “procedural” alternative functions (that are just methods in disguise) that we went to the bother of adding. If you really want a clever way of introducing exceptions into PHP without breaking huge amounts of existing code then how about this idea - change the language to detect if a function/method is being called within a try...catch block or not. If it is then throw an exception, but if it is not then use the old error handler. In this way the use of exceptions would not be forced on the developer and existing code would not break. This would me more work for the core developers, but no broken code in userland. By the way, it irks me (and many others) that PDO doesn’t throw exceptions by default. It really ought to, it’s an OOP API, I’d love to see that changed in PHP 7. Thanks. -- Andrea Faulds http://ajf.me/ -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
"Levi Morrison" wrote in message
news:CAFMT4NrH+=6B4=kvyrmw1oc0n-_onndjawk0xzcxdvnv_pn...@mail.gmail.com...
We are talking about something deprecated since 10 years, about the 1st
major release in a decade, something we will use for the next 12-14
years.
That is the point - PHP 4 constructors have NOT been marked as deprecated
in
the manual, and they produce no warnings at runtime.
If they have not been marked as deprecated then you cannot suddenly
remove
them.
Warning: a long response with code snippets/
See this code (http://3v4l.org/ViPpb):
class Test {
function test() {
echo __METHOD__, PHP_EOL;
}
function __construct() {
echo __METHOD__, PHP_EOL;
}
}
new Test();
Note that there is an E_STRICT generated for having both constructor
types in all versions of PHP 5 and that `__construct` is actually used
as the constructor.
An error is only generated if I use BOTH types of constructor in the same
class. If I use the PHP 4 constructor on its own then no error is generated.
<>
To me this clearly indicates three things:
1. Having both forms of constructors is bad form (hence the E_STRICT)
I agree.
2. When both are present the new-style __construct is used over the
old-style PHP 4 constructor, meaning the language prefers
__constructor.
I agree.
3. Old-style constructors don't exist in namespaces. Notably this
was a conscious choice as evidenced by behavior that existed in PHP
5.3.0 - 5.3.2 where the E_STRICT was emitted like non-namespaced code.
The fact that namespaces completely ignore a non-deprecated feature of the
language is a fault in the namespace implementation.
This is the behavior of shipped, stable versions of PHP. I think it's
a bit illogical to conclude that just because there aren't any
E_DEPRECATED warnings emitted in PHP 5 that old-style constructors are
fully supported.
My point is that if all constructors are PHP 4 style only then no error is
generated at all. It is therefore wrong to say that PHP 4 constructors have
been deprecated. The manual certainly does NOT say that they are deprecated.
That leaves us realistically with four options:
1. Bring full support for PHP 4 constructors
Good idea. Perhaps the RFC on default constructors should be extended to
cover both styles of constructor, in which case a call to
parent::__construct() will never fail regardless of whether a constructor
actually exists or not, or whether it is and old or new style constructor.
An existing feature should not be removed from the language unless it causes
a problem as its removal will not solve any problem and therefore cannot be
justified. If there is a problem then here are two choices:
(a) Fix the problem.
(b) Remove the feature.
Option (a) may involve a bit more work for the core developers, but option
(b) will always cause massive amounts of pain in userland and will slow down
the adoption rate for that release.
Any core developer who chooses option (b) is admitting two things:
(a) They don't know how to fix the problem.
(b) They don't care how much pain they cause for their customers all those
developers who create applications which run on over 240 million websites.
2. Emit E_DEPRECATED when PHP 4 constructors are used
3. Drop support for PHP 4 constructors so they are just normal
methods, just as they are in namespaces
4. Maintain current behavior.
As already mentioned I think as an end result we shouldn't have two
ways to define constructors.
Then why was a different method introduced in PHP 5 in the first place?
There was nothing wrong with PHP 4 constructors as they follow other
languages such as Java, C++ and C#, so they could never be described as
either wrong or inconsistent.
Given that PHP already prefers the
new-style constructors I've proposed that we work towards dropping the
old-style, it's just down to a matter of how.
Forcing your personal preferences on the rest of the PHP community will do
nothing but diminish your stature as a core developer in the eyes of those
members of the community who have different preferences. This is the
attitude of a small-minded dictator.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
"Levi Morrison" wrote in message news:cafmt4nopoeohga+uorsjrxosrh4k3eid96-jmmoqghct8uj...@mail.gmail.com... On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth wrote: On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote: <> According to the PHP.net documentation on E_STRICT(http://php.net/manual/en/migrating5.errorrep.php): When enabled, messages will be issued to warn you about code usage which is deprecated or which may not be future-proof. By very definition E_STRICT warns about this kind of thing. They've been there for *more than ten years*. But only when you use both PHP 4 and PHP 5 constructors at the same time. If a class uses ONLY the PHP 4 constructor then no message is generated at all. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
"Rowan Collins" wrote in message news:54baba93.9070...@gmail.com... On 17/01/2015 18:33, Todd Ruth wrote: As already mentioned I think as an end result we shouldn't have two >ways to define constructors. Given that PHP already prefers the >new-style constructors I've proposed that we work towards dropping the >old-style, it's just down to a matter of how. I've been following these threads for about 10 years and beg that php internals continues to "live and let live". There have been many, many threads over the years from what I would call (with obvious bias) "OO fundamentalists". They seem to be at war with code that is "bad form". This is an argument that comes up a lot, and it has some merit, sometimes. I don't think using __construct over named-method for constructors really has anything to do with "OOP fundamentalism"; it was a design change to make certain things simpler (like parent::__construct), This problem is partly solved in the RFC for Default Constructors (see https://wiki.php.net/rfc/default_ctor). If this were extended to cope with PHP 4 style constructors as well then all the problems would be solved. Then there would be no need to remove PHP 4 constructors at all. and more consistent (all reserved magic methods begin with __, so any method not beginning with that is safe to use however you like). In the global cost/benefit analysis I don't see that the benefits of purifying OO outweigh the costs. Not everything is a matter of code style - supporting legacy features comes at a cost in complexity, All compilers are complex beasts - that is the nature of compilers. If you cannot handle that complexity you shouldn't be working on a compiler. and sometimes even performance. Whenever new features are added - such as the ability to call parent::__construct when the parent doesn't declare a constructor explicitly - decisions have to be made on how they interact with old features - such as PHP4-style constructors. And simply by having an accumulation of old features, the codebase is larger, harder to understand, harder to change, and has more surface area for bugs. Removing long-standing features for no good reason (and a change in style is never a good reason) does nothing more than frustrate all those 240 million website owners who find that their existing applications will no longer run. This is the primary reason why there is a slow adoption rate for each new release. If you stop breaking the language then the adoption rate will be quicker. Deprecating a feature or raising an E_STRICT doesn't, of course, reduce this complexity by itself - indeed, it slightly increases it - but it paves the way for a future version to decide that this feature is no longer supported, and can be removed in order to improve the rest of the engine. So, you are quite right to highlight the costs of doing this, and they may well outweigh the benefits in this case. However, you are wrong to assume that the only benefit to be weighed is "purifying OO". Yet the reasons I have seen for removing an existing feature are rarely to fix a problem but to make the language "cleaner" or "more consistent". What this means in reality is "PHP would be cleaner if it didn't contain all those features that I don't like and I don't use, and I don't want anybody else to use them either". Regards, -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
"Andrea Faulds" wrote in message
news:d554c8b8-0bfb-44f7-b23e-8bfc12ae2...@ajf.me...
Hey Rowan,
On 17 Jan 2015, at 19:40, Rowan Collins wrote:
On 17/01/2015 18:33, Todd Ruth wrote:
<>
I don't think using __construct over named-method for constructors really
has anything to do with "OOP fundamentalism"; it was a design change to
make certain things simpler (like parent::__construct), and more
consistent (all reserved magic methods begin with __, so any method not
beginning with that is safe to use however you like).
To add on to what you said, there’s also a quite important benefit that
__construct is a lot more obvious in what it does.
Looking at the following code:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function foo() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
It’s not easy to spot the constructor at a glance, and it’s very easy to
miss.
Compare that to the following:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function __construct() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
Far more obvious.
If a developer cannot read valid code then it is a developer problem. It is
not up to the language to dictate style - it provides the functions and
features while style and readability are the sole responsibility of the
individual developer.
This actually tripped me up on more than one occasion when updating tests
broken by the removal of PHP 4 constructors in php-src.
Perhaps this issue can be solved by the RFC on Default Constructors? See
https://wiki.php.net/rfc/default_ctor
Sure, the constructor should probably be the first method, but *even if it
is* it’s still nowhere near as obvious in PHP 4 style.
Similarly, what does the following do?
$this->foo();
It looks like a normal method call, and it is in a sense. But if you’re in
Bar and inheriting from Foo, that’s a call to the parent class’s
constructor!
Perhaps there should be a new rule which says that invoking a constructor
with anything other than "new" or "parent::__contruct()" should be illegal,
in which case this situation would generate an error.
The following is much more obvious:
parent::__construct();
I think it’s pretty clear why we changed to PHP5-style constructors. They’re
just a lot more recognisable. :)
--
Andrea Faulds
http://ajf.me/
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
> Perhaps there should be a new rule which says that invoking a constructor
> with anything other than "new" or "parent::__contruct()"
> should be illegal, in which case this situation would generate an error.
Now this would break a lot of code that $obj->__construct(); or
$this->__construct(); And I've seen a lot of it.
2015-01-18 9:33 GMT-03:00 Tony Marston :
> "Andrea Faulds" wrote in message
> news:d554c8b8-0bfb-44f7-b23e-8bfc12ae2...@ajf.me...
>>
>>
>> Hey Rowan,
>>
>>> On 17 Jan 2015, at 19:40, Rowan Collins wrote:
>>>
>>> On 17/01/2015 18:33, Todd Ruth wrote:
>
>
> <>
>
>
>>> I don't think using __construct over named-method for constructors really
>>> has anything to do with "OOP fundamentalism"; it was a design change to make
>>> certain things simpler (like parent::__construct), and more consistent (all
>>> reserved magic methods begin with __, so any method not beginning with that
>>> is safe to use however you like).
>>
>>
>> To add on to what you said, there’s also a quite important benefit that
>> __construct is a lot more obvious in what it does.
>>
>> Looking at the following code:
>>
>> class Foo {
>>public $foo,
>> $bar,
>> $qux;
>>public function foobar() {
>>// ...
>>}
>>public function bar() {
>>// ...
>>}
>>public function foo() {
>>// ...
>>}
>>public function baz() {
>>// ...
>>}
>>public function qux() {
>>// ...
>>}
>> }
>>
>> It’s not easy to spot the constructor at a glance, and it’s very easy to
>> miss.
>>
>> Compare that to the following:
>>
>> class Foo {
>>public $foo,
>> $bar,
>> $qux;
>>public function foobar() {
>>// ...
>>}
>>public function bar() {
>>// ...
>>}
>>public function __construct() {
>>// ...
>>}
>>public function baz() {
>>// ...
>>}
>>public function qux() {
>>// ...
>>}
>> }
>>
>> Far more obvious.
>
>
> If a developer cannot read valid code then it is a developer problem. It is
> not up to the language to dictate style - it provides the functions and
> features while style and readability are the sole responsibility of the
> individual developer.
>
>> This actually tripped me up on more than one occasion when updating tests
>> broken by the removal of PHP 4 constructors in php-src.
>
>
> Perhaps this issue can be solved by the RFC on Default Constructors? See
> https://wiki.php.net/rfc/default_ctor
>
>> Sure, the constructor should probably be the first method, but *even if it
>> is* it’s still nowhere near as obvious in PHP 4 style.
>>
>> Similarly, what does the following do?
>>
>>$this->foo();
>>
>> It looks like a normal method call, and it is in a sense. But if you’re in
>> Bar and inheriting from Foo, that’s a call to the parent class’s
>> constructor!
>
>
> Perhaps there should be a new rule which says that invoking a constructor
> with anything other than "new" or "parent::__contruct()" should be illegal,
> in which case this situation would generate an error.
>
>> The following is much more obvious:
>>
>>parent::__construct();
>>
>> I think it’s pretty clear why we changed to PHP5-style constructors.
>> They’re just a lot more recognisable. :)
>> --
>> Andrea Faulds
>> http://ajf.me/
>>
>>
>>
>
> --
> Tony Marston
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi, > Please don't construe the willingness to add E_STRICTs with agreement > that such code should be forcibly eliminated. If there were a fully > automated tool to bring code into compliance, I would feel a lot better > about such changes, but even then, many of us would be applying that > tool to third-party code that has been lying around for a decade > untouched, and that's scary. such a tool has been proposed and even without it, it's a matter of (tedious) search & replace; > I suppose my opinion on these things is formed by my life experience > with these issues and since I don't doubt we all mean well, I guess the > OO purists probably are approaching this from different life > experiences. Here is where I'm coming from: This is not about purism. Leaving support for PHP4 constructors in the code means this code must be maintained for every core change that affects constructors. > To this day, we > still don't use namespaces or exceptions. No part of PHP forces you to write your code this way. You can still work with "Error classes" or "Error return values" and so on. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Fixing strange foreach behavior.
On 18 January 2015 at 01:01, Yasuo Ohgaki wrote: > Hi Rowan, > > On Sat, Jan 17, 2015 at 8:43 PM, Rowan Collins > wrote: > >> My concern is, at what cost? Given how rarely used the internal pointer >> is, >> are we carrying around a chunk of extra memory with every array just on >> the >> off-chance that it will be used, or is there some magic that makes it >> zero-width until it's needed? >> >> Reusing it for foreach makes perfect sense if it increases performance for >> the majority of cases, and the only way to cover every edge-case like the >> one at the top of this thread would be to ban that optimisation outright. >> If there's some way of separating things such that the rarely used >> constructs take the performance hit, I'm all for it, though. >> > > External position pointer needs a little more memory for sure. However, > external position pointer is used all over the place in standard and other > modules. > > I agree that some benchmark should be taken before we proceed. > I meant more that the internal pointer takes up memory which is unused by 99% of PHP applications, so we might as well get some benefit from it, but it comes to the same thing. > Alternatively, we could achieve consistency the other way round, by making >> foreach() reset the internal pointer even when it *doesn't* use it, and >> documenting that fact like we do for certain array functions. Code relying >> on the current behaviour when mixing them is probably buggy anyway, >> because >> it is not well-defined, so the BC concern should be low. >> > > IIRC, there were discussions when foreach is added that point out internal > position > pointer usage. Before foreach, everyone was using > current()/next()/reset(). I think > the reason foreach sets internal position pointer to the end was the code > used in > those days. It was not a technical/performance reasons, wasn't it? I don't > remember > well because it was more than 10 years ago. Anyone? > > IIRC, foreach was introduced by Andi. I think foreach used external > position pointer and > didn't touch internal position pointer at all with his first proposal. > Please correct me if I'm > wrong. > > As for nesting, I think PHP is doing the right thing for plain arrays and >> non-rewindable integrators, because I would expect a for each loop to >> start >> at the beginning, thus have an implicit reset/rewind. The rewindable >> behaviour is awkward, though - intuitively, the iteraror needs to be able >> to track multiple positions simultaneously, which isn't guaranteed by the >> interface design. Maybe an error should be issued if the integrator is >> already subject of a foreach loop? >> > > Iterator is headache, I agree. > Iterator nesting may be detected by a flag easily, but it may be better to > generate > independent iterators for each "foreach". > > I don't think that's an either/or situation: in most cases, it would be up to the user to create that independent iterator, because there's no general algorithm for cloning one that the engine could use. (Think of an iterator proxying a database cursor, for instance - it could be rewindable directly, but cloning it would imply issuing a new query to create a new cursor with separate state.) So the engine needs to issue an error telling the user that they're reusing an object in an dangerous way. An extended interface could be created later for those cases that can handle the situation, although I doubt it would be that common a use case. -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 18 January 2015 at 12:23, Tony Marston wrote: > "Rowan Collins" wrote in message news:54baba93.9070...@gmail.com... > >> >> On 17/01/2015 18:33, Todd Ruth wrote: >> >>> As already mentioned I think as an end result we shouldn't have two >ways to define constructors. Given that PHP already prefers the >new-style constructors I've proposed that we work towards dropping the >old-style, it's just down to a matter of how. >>> I've been following these threads for about 10 years and beg that php >>> internals continues to "live and let live". >>> There have been many, many threads over the years from what I would call >>> (with obvious bias) "OO fundamentalists". They seem to be at war with >>> code that is "bad form". >>> >> >> This is an argument that comes up a lot, and it has some merit, sometimes. >> >> I don't think using __construct over named-method for constructors really >> has anything to do with "OOP fundamentalism"; it was a design change to >> make certain things simpler (like parent::__construct), >> > > This problem is partly solved in the RFC for Default Constructors (see > https://wiki.php.net/rfc/default_ctor). If this were extended to cope with > PHP 4 style constructors as well then all the problems would be solved. > Then > there would be no need to remove PHP 4 constructors at all. > > That's a good example of supporting old features adding complexity. You're right, it could solve this problem, at the expense of extra code, with extra possibility of bugs. > and more consistent (all reserved magic methods begin with __, so any >> method not beginning with that is safe to use however you like). >> >> In the global cost/benefit analysis I don't see that the >>> benefits of purifying OO outweigh the costs. >>> >> >> Not everything is a matter of code style - supporting legacy features >> comes >> at a cost in complexity, >> > > All compilers are complex beasts - that is the nature of compilers. If you > cannot handle that complexity you shouldn't be working on a compiler. Saying that something is complex in no way justifies making it more complex; arguably, quite the opposite: compilers (and runtime engines) are complex enough at the best of times, so features which add to that complexity should be carefully evaluated to avoid the whole thing becoming an unmaintainable mess. > > > and sometimes even performance. Whenever new features are added - such as >> the ability to call parent::__construct when the parent doesn't declare a >> constructor explicitly - decisions have to be made on how they interact >> with old features - such as PHP4-style constructors. And simply by having >> an accumulation of old features, the codebase is larger, harder to >> understand, harder to change, and has more surface area for bugs. >> > > Removing long-standing features for no good reason (and a change in style > is > never a good reason) does nothing more than frustrate all those 240 million > website owners who find that their existing applications will no longer > run. > This is the primary reason why there is a slow adoption rate for each new > release. If you stop breaking the language then the adoption rate will be > quicker. I'm not sure why you've replied with a well-worn argument about "no good reason" to an e-mail whose sole purpose was pointing out a good reason. You may think my reason is not valid, but that doesn't make this paragraph remotely relevant or insightful. > > > Deprecating a feature or raising an E_STRICT doesn't, of course, reduce >> this complexity by itself - indeed, it slightly increases it - but it >> paves >> the way for a future version to decide that this feature is no longer >> supported, and can be removed in order to improve the rest of the engine. >> >> So, you are quite right to highlight the costs of doing this, and they may >> well outweigh the benefits in this case. However, you are wrong to assume >> that the only benefit to be weighed is "purifying OO". >> > > Yet the reasons I have seen for removing an existing feature are rarely to > fix a problem but to make the language "cleaner" or "more consistent". What > this means in reality is "PHP would be cleaner if it didn't contain all > those features that I don't like and I don't use, and I don't want anybody > else to use them either". > Again, you have opted to ignore my point rather than respond to it. I am not saying there is definitely sufficient justification to remove this particular feature, but the idea that PHP could simply continue forever to support every feature it has ever had, with no cost to anyone, and that therefore anyone wanting to remove things is some kind of selfish dictator is patently false. Those proposing changes should certainly justify the benefits, but those opposing should not simply pretend that those benefits cannot exist. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Class constructor behaviour
On 18 January 2015 at 11:28, Tony Marston wrote:
> "Andrea Faulds" wrote in message news:23490588-0131-4B0F-A7AA-
> c9c8c7666...@ajf.me...
>
>>
>> Hi François,
>>
>> On 17 Jan 2015, at 15:37, François Laupretre
>>> wrote:
>>>
>>> I would prefer deciding that returning null is the standard way for a
>>> constructor to inform the PHP core that the object creation failed (for any
>>> reason). This would be trapped by the core and cause a catchable fatal
>>> error.
>>>
>>> This is more compatible with the 'exception-less' behavior of the core
>>> in general. The constructor is still free to throw an exception but this
>>> wouldn't be encouraged nor the standard way to inform the core that an
>>> error occurred.
>>>
>>
>> I don’t really agree here. For some reason we have this tradition of not
>> using exceptions for “procedural” stuff. That sort of makes sense for
>> functions, but classes are “OOP” and therefore I don’t see a good reason
>> why they shouldn’t throw exceptions.
>>
>
> You are forgetting one minor thing - an object may be instantiated from a
> piece of procedural code. In fact the very first object can only be
> instantiated from procedural code.
I'm not sure what you mean by the second sentence here; which is the "very
first object"?
> The idea that every piece of code that uses "new" will have to be amended
> to be in a try...catch block is a huge amount of work that does not solve
> any problem (except to satisfy the delicate sensibilities of the OO
> purists).
Bear in mind that there are costs to users writing new code as well as
costs to those maintaining existing ones. When writing code from scratch,
it's actually much easier to write code with catch/finally than to check
for non-object returns before using every object. The errors for uncaught
exceptions are generally much easier for a new user to understand than the
errors for accessing a method on what turns out to be a null value not an
object.
>
>
> Exceptions and OOP (and namespaces, even) should not be the domain of
>> userland exclusively, they are also the domain of internals/core. If you
>> really hate exceptions, I’d say you should just use one of those ridiculous
>> “procedural” alternative functions (that are just methods in disguise) that
>> we went to the bother of adding.
>>
>
> If you really want a clever way of introducing exceptions into PHP without
> breaking huge amounts of existing code then how about this idea - change
> the language to detect if a function/method is being called within a
> try...catch block or not. If it is then throw an exception, but if it is
> not then use the old error handler. In this way the use of exceptions would
> not be forced on the developer and existing code would not break. This
> would me more work for the core developers, but no broken code in userland.
>
>
Unfortunately, that wouldn't be as useful as it sounds. Consider this code:
try { somefunc($foo); }
catch ( InvalidArgumentException $e ) { ... }
If somefunc() internally uses PDO, should it automatically switch to
exception-throwing mode, because a try-block is in the stack? Or should it
hunt in advance for matching catch() clauses, which would probably be
extremely slow? And if the user lazily writes catch(Exception $e) around a
top-level function, suddenly their whole application behaves differently,
because their inline error handling suddenly stops working?
Unfortunately, exceptions require a specific way of thinking, at least in
the area of code where they occur, because they don't neatly reduce to
equivalent linear code.
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] [RFC] [VOTE] Preserve Fractional Part in JSON encode
During the discussion process it was discussed and people were ok with it since it doesn't break any existing code. Also, JSON_NUMERIC_CHECK option was added on json_encode in patch version (added on 5.3.3). On Sun, Jan 18, 2015 at 12:37 AM, Pierre Joye wrote: > > On Jan 18, 2015 11:24 AM, "Juan Basso" wrote: > > > > The vote is now closed. By 14x0 the RFC was accepted. > > > > Since I am not part of the core team, who can merge the PR ( > > https://github.com/php/php-src/pull/642)? By the way, the RFC was > target to > > the next PHP 5.6 patch version, but the PR was target to master. Should I > > reopen the PR to PHP-5.6 branch? > > I miss that rfc and especially the part saying it targets next 5.x.y, aka > next 5.6. > > This is not good. We do not allow features addition to stable branch. > > Cheers, > Pierre >
[PHP-DEV] Re: [RFC] jsond
On Sun, Jan 11, 2015 at 5:27 PM, Jakub Zelenka wrote: > Hi, > > This rfc about replacing json with jsond is under discussion. > > https://wiki.php.net/rfc/jsond > > > I have added a bit more info to the RFC about the BC (the same info that was discussed here) and also added few more links. In addition the jsond PR has been updated by merging changes for the preserving fractional part RFC that has been recently accepted. Thanks to Juan Basso for sending the patch. ;) Cheers Jakub
Re: [PHP-DEV] PEAR and make install on master
On Sun, Jan 18, 2015 at 9:40 AM, Matteo Beccati wrote: > Hi, > > so, the removal of deprecated features has started and make install is now > rightfully failing because PEAR is installed by default, although it is not > compatible anymore: > > Installing PEAR environment: /home/atlassian/phpNext/lib/php/ > > Fatal error: Non-static method PEAR_Installer_Role::initializeConfig() > cannot be called statically, assuming $this from incompatible context in > phar:///.../pear/install-pear-nozlib.phar/PEAR/Config.php on line 599 > make[1]: *** [install-pear-installer] Error 255 > make: *** [install-pear] Error 2 > > I've tried to look up the pear MLs, but I haven't seen any recent > activity... what's the plan, if any? > That's a good question. As far as I understand we still need PEAR because it also provides the PECL installer. So it would be good if the installer is fixed. As an immediate action I would suggest to disable installation of PEAR by default, given how it should be irrelevant to most PHP users who don't install extensions via PECL. Nikita
Re: [PHP-DEV] Mind if I hook the compiler?
On Sun, Jan 18, 2015 at 3:58 AM, Sara Golemon wrote: > https://github.com/php/php-src/pull/1004 > > Wondering if anyone has an objection to me merging this. It just > offers extensions a chance to alter the AST prior to bytecode > emission. Mostly for evil things, but potentially for 3rd-party > optimizers or whatevs. Does it need an RFC? The very minor > indirection cost hides itself behind OpCache, so it should harm > anything... > Totally okay with making that hookable, but not sure if compile_top_stmt is the best place to do that, at least in the form implemented in the PR. Assuming that you want to implement a preprocessing pass on the AST the fast that zend_compile_top_stmt is called recursively might be somewhat inconvenient. Maybe compile_top_stmt should at least also call compile_top_stmt instead of zend_compile_top_stmt? Nikita
Re: [PHP-DEV] [RFC][Vote] Return Types
On Sat, Jan 17, 2015 at 4:42 PM, Yasuo Ohgaki wrote: > Hi Pierre and Levi, > > On Sat, Jan 17, 2015 at 3:05 PM, Pierre Joye wrote: >> >> On Fri, Jan 16, 2015 at 10:36 PM, Yasuo Ohgaki wrote: >> > Hi Simon and Levi, >> > >> > On Fri, Jan 16, 2015 at 4:53 PM, Simon J Welsh >> > wrote: >> > >> >> The tests have it after the use(): >> >> >> >> https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9 >> >> >> >> This was discussed in depth a couple of times in the related threads. >> >> >> > >> > Thank you for the information. It should be in the RFC. IMHO. >> > I feels natural to have type spec after function parameter definition >> > rather than >> > after "use". >> >> Please do not change the RFC during votes phase, or re start it. >> >> If many of the voters feel like they were voted on something different >> of what is being discussed here, it may be a good thing to restart it. >> However I think we all understood it as it is described in this >> thread. Let update it after the votes or for the docs. > > > Sounds good to me. > Let's update the RFC after vote. According to the previous discussion the return type goes after the use statement, and this is how it is implemented. There has not been an unintentional mistake here. If you disagree with that decision I am open to discussing it again. Since it isn't actually mentioned in the RFC (which was an oversight, I apologize) I'm not sure we'd have to revote on it. Anyone else have an opinion on this? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
On Sun, Jan 18, 2015 at 11:53 PM, Levi Morrison wrote: > On Sat, Jan 17, 2015 at 4:42 PM, Yasuo Ohgaki wrote: >> Hi Pierre and Levi, >> >> On Sat, Jan 17, 2015 at 3:05 PM, Pierre Joye wrote: >>> >>> On Fri, Jan 16, 2015 at 10:36 PM, Yasuo Ohgaki wrote: >>> > Hi Simon and Levi, >>> > >>> > On Fri, Jan 16, 2015 at 4:53 PM, Simon J Welsh >>> > wrote: >>> > >>> >> The tests have it after the use(): >>> >> >>> >> https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9 >>> >> >>> >> This was discussed in depth a couple of times in the related threads. >>> >> >>> > >>> > Thank you for the information. It should be in the RFC. IMHO. >>> > I feels natural to have type spec after function parameter definition >>> > rather than >>> > after "use". >>> >>> Please do not change the RFC during votes phase, or re start it. >>> >>> If many of the voters feel like they were voted on something different >>> of what is being discussed here, it may be a good thing to restart it. >>> However I think we all understood it as it is described in this >>> thread. Let update it after the votes or for the docs. >> >> >> Sounds good to me. >> Let's update the RFC after vote. > > According to the previous discussion the return type goes after the > use statement, and this is how it is implemented. There has not been > an unintentional mistake here. > > If you disagree with that decision I am open to discussing it again. > Since it isn't actually mentioned in the RFC (which was an oversight, > I apologize) I'm not sure we'd have to revote on it. Anyone else have > an opinion on this? Addint/editing it means a re vote. I do not think it is necessary at is pretty clear, or I think it is. At the very least, let wait after the vote ended, to see if complains will be raised. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PEAR and make install on master
On Sun, Jan 18, 2015 at 11:44 PM, Nikita Popov wrote: > On Sun, Jan 18, 2015 at 9:40 AM, Matteo Beccati wrote: > >> Hi, >> >> so, the removal of deprecated features has started and make install is now >> rightfully failing because PEAR is installed by default, although it is not >> compatible anymore: >> >> Installing PEAR environment: /home/atlassian/phpNext/lib/php/ >> >> Fatal error: Non-static method PEAR_Installer_Role::initializeConfig() >> cannot be called statically, assuming $this from incompatible context in >> phar:///.../pear/install-pear-nozlib.phar/PEAR/Config.php on line 599 >> make[1]: *** [install-pear-installer] Error 255 >> make: *** [install-pear] Error 2 >> >> I've tried to look up the pear MLs, but I haven't seen any recent >> activity... what's the plan, if any? >> > > That's a good question. As far as I understand we still need PEAR because > it also provides the PECL installer. So it would be good if the installer > is fixed. For pecl, we will propose to bundle pickle.phar, which basically provides 100% bc for existing packages and allow much more, like install from any URL/VCS based on composer, integration with composer (composer will call pickle for any php-ext dep). Last but not least, if one likes to drop "pecl install" support, he won't need to maintain package.xml, duplicate versions, meta and co but only the sources, config.* and README. I am waiting for the discussions+RFC about how to deal with 5 and 7 extensions support. Once we have a decision we will implement what is necessary for that in pickle. For the ref here: https://github.com/FriendsOfPHP/pickle Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Preserve Fractional Part in JSON encode
On Sun, Jan 18, 2015 at 11:27 PM, Juan Basso wrote: > During the discussion process it was discussed and people were ok with it > since it doesn't break any existing code. Also, JSON_NUMERIC_CHECK option > was added on json_encode in patch version (added on 5.3.3). I do not know who are the "people" but the release process is pretty clear on that. We decided not to allow features additions to ease developers life, like not having to do dozen of tests to know which minor versions added what. It is also why we have yearly releases, reduce the delay between accepted features and actual availability in a release. Please not that the release process was approved after 5.3 and applied to 5.4+. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Preserve Fractional Part in JSON encode
On Sun, Jan 18, 2015 at 6:02 PM, Pierre Joye wrote: > On Sun, Jan 18, 2015 at 11:27 PM, Juan Basso wrote: > > During the discussion process it was discussed and people were ok with it > > since it doesn't break any existing code. Also, JSON_NUMERIC_CHECK option > > was added on json_encode in patch version (added on 5.3.3). > > > I do not know who are the "people" but the release process is pretty > clear on that. We decided not to allow features additions to ease > developers life, like not having to do dozen of tests to know which > minor versions added what. It is also why we have yearly releases, > reduce the delay between accepted features and actual availability in > a release. > > Please not that the release process was approved after 5.3 and applied to > 5.4+. > The release process RFC *explicitly* allows the addition of self-contained features in patch releases. This rule is implemented in practice either by RM approval for the feature or an RFC, the latter being the case here. Nikita
Re: [PHP-DEV] [RFC] [VOTE] Preserve Fractional Part in JSON encode
On Jan 19, 2015 12:13 AM, "Nikita Popov" wrote: > > On Sun, Jan 18, 2015 at 6:02 PM, Pierre Joye wrote: >> >> On Sun, Jan 18, 2015 at 11:27 PM, Juan Basso wrote: >> > During the discussion process it was discussed and people were ok with it >> > since it doesn't break any existing code. Also, JSON_NUMERIC_CHECK option >> > was added on json_encode in patch version (added on 5.3.3). >> >> >> I do not know who are the "people" but the release process is pretty >> clear on that. We decided not to allow features additions to ease >> developers life, like not having to do dozen of tests to know which >> minor versions added what. It is also why we have yearly releases, >> reduce the delay between accepted features and actual availability in >> a release. >> >> Please not that the release process was approved after 5.3 and applied to 5.4+. > > > The release process RFC *explicitly* allows the addition of self-contained features in patch releases. This rule is implemented in practice either by RM approval for the feature or an RFC, the latter being the case here. Except that this one is not self contained and the rfc says in rare cases (or say, for good reason). I give up to try explain where the constant lack of respect of the RFC will lead. That's why I won't battle for this now.
Re: [PHP-DEV] Mind if I hook the compiler?
On Sun, Jan 18, 2015 at 8:50 AM, Nikita Popov wrote:
> Totally okay with making that hookable, but not sure if compile_top_stmt is
> the best place to do that, at least in the form implemented in the PR.
> Assuming that you want to implement a preprocessing pass on the AST the fast
> that zend_compile_top_stmt is called recursively might be somewhat
> inconvenient. Maybe compile_top_stmt should at least also call
> compile_top_stmt instead of zend_compile_top_stmt?
>
I did think about that, and ended up with this spot on the idea that
one could just let the main implementation worry about recursive, and
only alter patters as they're seen.
For example, if my extension wants only wants to do constant folding,
I might wait until I get fed an ast node for looking up constants
rather than drilling down myself, then leaving the engine to drill
down again.
That said, I'm not married to that approach, I could add the hook more
here instead and be just as happy:
diff --git a/Zend/zend_language_scanner.l b/Zend/zend_language_scanner.l
index 2412631..0ebf0c2 100644
--- a/Zend/zend_language_scanner.l
+++ b/Zend/zend_language_scanner.l
@@ -586,6 +586,9 @@ ZEND_API zend_op_array
*compile_file(zend_file_handle *file_handle, int type)
if (compiler_result != 0) { /* parser error */
zend_bailout();
}
+ if (zend_ast_hook) {
+ zend_ast_hook(CG(ast));
+ }
zend_compile_top_stmt(CG(ast));
zend_ast_destroy(CG(ast));
zend_arena_destroy(CG(ast_arena));
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
On Sun, Jan 18, 2015 at 9:55 AM, Pierre Joye wrote: > On Sun, Jan 18, 2015 at 11:53 PM, Levi Morrison wrote: >> On Sat, Jan 17, 2015 at 4:42 PM, Yasuo Ohgaki wrote: >>> Hi Pierre and Levi, >>> >>> On Sat, Jan 17, 2015 at 3:05 PM, Pierre Joye wrote: On Fri, Jan 16, 2015 at 10:36 PM, Yasuo Ohgaki wrote: > Hi Simon and Levi, > > On Fri, Jan 16, 2015 at 4:53 PM, Simon J Welsh > wrote: > >> The tests have it after the use(): >> >> https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9 >> >> This was discussed in depth a couple of times in the related threads. >> > > Thank you for the information. It should be in the RFC. IMHO. > I feels natural to have type spec after function parameter definition > rather than > after "use". Please do not change the RFC during votes phase, or re start it. If many of the voters feel like they were voted on something different of what is being discussed here, it may be a good thing to restart it. However I think we all understood it as it is described in this thread. Let update it after the votes or for the docs. >>> >>> >>> Sounds good to me. >>> Let's update the RFC after vote. >> >> According to the previous discussion the return type goes after the >> use statement, and this is how it is implemented. There has not been >> an unintentional mistake here. >> >> If you disagree with that decision I am open to discussing it again. >> Since it isn't actually mentioned in the RFC (which was an oversight, >> I apologize) I'm not sure we'd have to revote on it. Anyone else have >> an opinion on this? > > Addint/editing it means a re vote. I did not mean editing it during vote; I meant that since the RFC does not actually address this point it isn't technically included in the vote. This means that if it passes we could alter this behavior if desired while still being true to the vote. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
Hey Pierre, > On 18 Jan 2015, at 16:55, Pierre Joye wrote: > > Addint/editing it means a re vote. I don’t think this is always true. For minor changes to the RFC text that provide clarifications and do not change the actual proposal, there’s no problem with editing during voting. In this case, the position of the return type in the anonymous function syntax isn’t a new detail of the proposal, as it was already in the patch. Adding it to the RFC would just help clear things up. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Preserve Fractional Part in JSON encode
Hey Pierre, > On 18 Jan 2015, at 17:17, Pierre Joye wrote: > > Except that this one is not self contained and the rfc says in rare cases > (or say, for good reason). Does it? With the flag turned off (default), behaviour is exactly the same as before. With the flag on, behaviour is changed. Seems fairly self-contained to me, just an extra flag. It does affect performance, but positively, so not a problem. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
On Jan 19, 2015 1:21 AM, "Andrea Faulds" wrote: > > Hey Pierre, > > > On 18 Jan 2015, at 16:55, Pierre Joye wrote: > > > > Addint/editing it means a re vote. > > I don’t think this is always true. For minor changes to the RFC text that provide clarifications and do not change the actual proposal, there’s no problem with editing during voting. > > In this case, the position of the return type in the anonymous function syntax isn’t a new detail of the proposal, as it was already in the patch. Adding it to the RFC would just help clear things up. If the RFC is not clear, it should not proposed to vote on in the 1st place. There must be no edit during the vote phase. It has abused too often already. Be ready or wait until you are. > Thanks. > > -- > Andrea Faulds > http://ajf.me/ > > > >
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
Hi! > Yes, like I said, I am aware that the comparison function is flaky > but it is still code that has worked for 15 years so we have to be > clear about the BC break. The fact that it works up until the array Looking at that function, I'm not sure the fact it worked is not pure luck. It is not an order function - it produces different result when parameters are switched, i.e. if you call f($a, $b) it would say $a > $b, but if you call f($b, $a) it would say $a == $b. Of course, even broken functions can produce valid results, with some luck, but I'm not sure we can guarantee non-order functions to work when order function is required. It's too bad PHP does not have <=> operator (which, along with being useful for writing functions exactly like this, has a cool name "spaceship operator" :) We have an RFC on that: https://wiki.php.net/rfc/combined-comparison-operator but it seems to be stalled. Maybe we should revive it? > gets more than 16 elements makes it a tricky one to track down for > people. With the massive volume of legacy code out there we have to > be careful with changes like this that can break existing code, even > if that code is questionable. I agree in principle, but in this case the code is not "questionable", it's wrong. If we use an order-based algorithm, the function should satisfy basic rules for order - i.e. $a == $a, if $a < $b then $b > $a, if $a > $b and $b > $c then $a > $c, etc. If it does not, I don't think we can guarantee anything here. > At the very least we need a clear note in the upgrading doc reminding > people to check all their user comparison functions. That is a good idea, knowing that the change can expose previously hidden bugs is useful. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mind if I hook the compiler?
Hi! On 1/17/15 6:58 PM, Sara Golemon wrote: > https://github.com/php/php-src/pull/1004 > > Wondering if anyone has an objection to me merging this. It just > offers extensions a chance to alter the AST prior to bytecode No objection but I wonder if it's time to have some list of the hooks - especially in the light of the effort for making ZE API look like an API. Also, I like "pre-processor hook" a bit better (second patch). -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
On 01/18/2015 11:45 AM, Stanislav Malyshev wrote: > Hi! > >> Yes, like I said, I am aware that the comparison function is flaky >> but it is still code that has worked for 15 years so we have to be >> clear about the BC break. The fact that it works up until the array > > Looking at that function, I'm not sure the fact it worked is not pure > luck. It is not an order function - it produces different result when > parameters are switched, i.e. if you call f($a, $b) it would say $a > > $b, but if you call f($b, $a) it would say $a == $b. Of course, even > broken functions can produce valid results, with some luck, but I'm not > sure we can guarantee non-order functions to work when order function is > required. Sure, I understand it is flaky. But it is still code that has always worked in every single version of PHP (and HHVM) ever released going back 15+ years. eg. http://3v4l.org/7prWJ and I have a php3 build here that it works on as well. We have to be really really careful with this "oh, that code is wrong, so we can break it argument". This will break hundreds if not thousands of sites in a hard-to-debug way. It took me less than a minute of looking on Github to find a case that will break: https://github.com/chenboking/service.downloadmanager.amule/blob/cda510415f9a58660e096a7de42b3ea6f39ee851/webserver/php-default/amuleweb-main-search.php#L121 It is extremely common to just do a less-than or a greater-than check in a user comparison function. Of course it isn't textbook-correct, but since it has always worked, people do it. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [VOTE] Remove deprecated functionality in PHP 7
Hi Nikita, On Sun, Jan 18, 2015 at 8:01 PM, Nikita Popov wrote: > That would be appreciated! When dropping the ini settings, please make > sure that it's still possible to use Zend multibyte. If I remember > correctly, right now Zend multibyte can only be used with the deprecated > mbstring.internal_encoding setting, but not using php.internal_encoding. Thank you for reminding! I'll get rid of old INIs after I finished session changes that is supposed to be included in PHP 5.6. Spending hours to get used to new PHP 7 APIs. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
On 01/18/2015 02:08 PM, Rasmus Lerdorf wrote:
> We have to be really really careful with this "oh, that code is wrong,
> so we can break it argument". This will break hundreds if not thousands
> of sites in a hard-to-debug way. It took me less than a minute of
> looking on Github to find a case that will break:
>
> https://github.com/chenboking/service.downloadmanager.amule/blob/cda510415f9a58660e096a7de42b3ea6f39ee851/webserver/php-default/amuleweb-main-search.php#L121
>
> It is extremely common to just do a less-than or a greater-than check in
> a user comparison function. Of course it isn't textbook-correct, but
> since it has always worked, people do it.
And just to further illustrate this, I just downloaded the current
Wordpress release and sure enough, Wordpress would also be broken by
this change.
In http://core.svn.wordpress.org/trunk/wp-includes/class-simplepie.php
look at the sort_items() method:
/**
* Sorting callback for items
*
* @access private
* @param SimplePie $a
* @param SimplePie $b
* @return boolean
*/
public static function sort_items($a, $b)
{
return $a->get_date('U') <= $b->get_date('U');
}
I am not saying we should revert the change, but we need to be very
aware of the effect this change will have on PHP7 adoption. The really
nasty part is that even if a big codebase has unit tests covering the
code, unless the unit test actually tests an array with more than 16
elements, all tests will pass and the application will only fail in
production with production data. And there are no errors or warnings of
any sort either that will help people track this down.
This will need to be front and center in the UPGRADING doc with an
explanation about how to write a proper ordering function.
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
Hey Rasmus,
> On 19 Jan 2015, at 04:52, Rasmus Lerdorf wrote:
>
>> On 01/18/2015 02:08 PM, Rasmus Lerdorf wrote:
>> We have to be really really careful with this "oh, that code is wrong,
>> so we can break it argument". This will break hundreds if not thousands
>> of sites in a hard-to-debug way. It took me less than a minute of
>> looking on Github to find a case that will break:
>>
>> https://github.com/chenboking/service.downloadmanager.amule/blob/cda510415f9a58660e096a7de42b3ea6f39ee851/webserver/php-default/amuleweb-main-search.php#L121
>>
>> It is extremely common to just do a less-than or a greater-than check in
>> a user comparison function. Of course it isn't textbook-correct, but
>> since it has always worked, people do it.
>
> And just to further illustrate this, I just downloaded the current
> Wordpress release and sure enough, Wordpress would also be broken by
> this change.
>
> In http://core.svn.wordpress.org/trunk/wp-includes/class-simplepie.php
> look at the sort_items() method:
>
>/**
> * Sorting callback for items
> *
> * @access private
> * @param SimplePie $a
> * @param SimplePie $b
> * @return boolean
> */
>public static function sort_items($a, $b)
>{
>return $a->get_date('U') <= $b->get_date('U');
>}
>
> I am not saying we should revert the change, but we need to be very
> aware of the effect this change will have on PHP7 adoption. The really
> nasty part is that even if a big codebase has unit tests covering the
> code, unless the unit test actually tests an array with more than 16
> elements, all tests will pass and the application will only fail in
> production with production data. And there are no errors or warnings of
> any sort either that will help people track this down.
>
> This will need to be front and center in the UPGRADING doc with an
> explanation about how to write a proper ordering function.
Related: since we have no Perl-like spaceship operator ($a <=> $b), writing
comparison functions is unnecessarily complex in the common case, as you must
produce -1, 0, 1 yourself.
Could we expose a cmp() or compare() function that calls our internal
comparison operator? This would make writing custom sort functions a lot nicer,
and quite possibly improve some other kinds of code.
That would also mean a future sorting API could unify user sorts and non-user
sorts: just make the default callback be cmp().
Usage would be like this:
cmp(1, 2); // 1
cmp(1, 1); // 0
cmp(2, 1); // 1
Essentially, exactly like the spaceship in Perl, but a function.
Thoughts?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
On 01/18/2015 09:00 PM, Andrea Faulds wrote: > That would also mean a future sorting API could unify user sorts and non-user > sorts: just make the default callback be cmp(). > > Usage would be like this: > > cmp(1, 2); // 1 > cmp(1, 1); // 0 > cmp(2, 1); // 1 > > Essentially, exactly like the spaceship in Perl, but a function. > > Thoughts? Well, if you really meant that would be the output, perhaps we should get someone else to write it. :) -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
> On 19 Jan 2015, at 05:03, Rasmus Lerdorf wrote: > > On 01/18/2015 09:00 PM, Andrea Faulds wrote: >> That would also mean a future sorting API could unify user sorts and >> non-user sorts: just make the default callback be cmp(). >> >> Usage would be like this: >> >> cmp(1, 2); // 1 >> cmp(1, 1); // 0 >> cmp(2, 1); // 1 >> >> Essentially, exactly like the spaceship in Perl, but a function. >> >> Thoughts? > > Well, if you really meant that would be the output, perhaps we should > get someone else to write it. :) I noticed that erratum the moment after I sent the email. Oh, if only emails could be edited *after* being sent… The output would be: cmp(1, 2); // -1 cmp(1, 1); // 0 cmp(2, 1); // 1 There should’ve been a minus sign on the third one, a typo. But I’d forgotten that comparison functions actually go the other way round. I suppose this proves my point that cmp() would make things easier ;) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class constructor behaviour
Hi! > This is pretty horrible and should be fixed by making sure that I don't see why it's so horrible. In fact, handling null is easier than handling exception (and faster too, probably). Many functions that try to create objects return null or false when unable to. Of course, we could change it by introducing exceptions to core, but I don't see why do it peacemeal then. > constructors either return an object or throw an exception. > Additionally the exception policy for core (that was previously > discussed here: http://marc.info/?t=11926374801&r=1&w=2 ) should > be updated so that any constructor returning NULL is considered a bug, > no matter what the ini settings are. To be clear, procedural code > should behave as before, with users expected to check for errors. > This would be a BC break for people who are handling the constructor > returning null currently, as they would need to wrap that code with an > try/catch block. That means the same failure of collator construction now needs to be handled in two different ways. > Constructors give warning, but are then in an unusable state > > Several constructors check the parameters that they are given.and > then just give a warning when they are not acceptable. e.g. These should be fixed to either return null or throw exception, but the behavior should be unified for everybody. > Again, this should be fixed by changing the constructors to throw an > exception if the input parameters are not acceptable. The next question would be - if the ctors throw an exceptions, why factory methods shouldn't? They are doing the same work essentially. > Constructor gives error > --- > > Some constructors check the parameters they are given, and then emit > either a 'Catchable fatal error' error or other error e.g. This is even bigger can of worms. If we wrote PHP today from scratch, catchable fatal errors would be exceptions. But they are not, so we need to deal with it - by either leaving them as is, or converting them all together. > > $foo = new IntlGregorianCalendar(new StdClass); > //Output: Catchable fatal error: Object of class stdClass could not be > converted to string in.. This is not property of the ctor, it's property of parameter handling. I.e. if you do it for IntlGregorianCalendar, you should do it for every class that gets incompatible parameters. And probably user-space funcs too since there's no reason for them to behave differently. I actually wouldn't mind that, but this is yet bigger can of worms as it requires refactoring a lot of assumptions on how parameters are parsed. > i) Can anyone see a big hurdle in fixing these behaviours, other than > it being a BC break for people who are currently relying on these > behaviours ? Yes. The first hurdle is to understand which of these behaviors need fixing, and how, which you seem to dismiss as obvious but it's really not. The second is to do it in consistent manner so it doesn't again come out as part of the functions do one thing, another part another, and third part something else different. > ii) Are there any other bad behaviours that people are aware of that > ought to be fixed at a major version? I think we have enough for now to discuss here, so if we want do discuss other behaviors better to open separate thread. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
> On 19 Jan 2015, at 05:00, Andrea Faulds wrote: > > Related: since we have no Perl-like spaceship operator ($a <=> $b), writing > comparison functions is unnecessarily complex in the common case, as you must > produce -1, 0, 1 yourself. > > Could we expose a cmp() or compare() function that calls our internal > comparison operator? This would make writing custom sort functions a lot > nicer, and quite possibly improve some other kinds of code. > > That would also mean a future sorting API could unify user sorts and non-user > sorts: just make the default callback be cmp(). > > Usage would be like this: > > cmp(1, 2); // 1 > cmp(1, 1); // 0 > cmp(2, 1); // 1 > > Essentially, exactly like the spaceship in Perl, but a function. > > Thoughts? I went ahead and implemented it, since it’s so trivial: https://github.com/php/php-src/pull/1006 Should I write an RFC, or could we just merge this without needing one? I’m also wondering if numcmp(), to do “numeric comparison” might also be a good idea. Currently it’s the same as cmp((float)$val1, (float)$val2); but that might (and probably should, that leads to inaccurate sorting!) change in future. Thoughts? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class constructor behaviour
Hi!
> A constructor that fails is a hard failure (factory method failed to
> produce the expected value), and is an exceptional case that can or cannot
> be handled (via catch).
> It's not just a failed operation (expected to eventually fail), but
> something really went wrong, badly.
Why it is different from any other failure? I.e. fopen("doesnotexist",
"r") produces false and it's not "hard failure". But if files were
objects, new File("doesnotexist", File::READONLY) suddenly becomes "hard
failure"? How the latter is harder than the former? I would say it's
exactly the same. If you say "new File" can only throw, you should also
say fopen() should only throw. If fopen can return error value, so can
File::open(), so can new File.
The difference would be if File object would be built so that "new File"
should never fail, and opening would be done with "$file->open()" and
not with the ctor. But most of the object APIs in PHP are not written
this way - for these APIs, ctor failure is not something exceptional
more than failing to open file is exceptional.
> Additionally, it makes no sense to have inconsistent behavior between
> internal classes and userland classes: it is currently impossible for a
> userland class to have the `new` operator producing an object that is not
> an instance of the class after that operator.
That can be changed if needed. This is just a missing feature.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
Hey:
On Mon, Jan 19, 2015 at 12:52 PM, Rasmus Lerdorf wrote:
> On 01/18/2015 02:08 PM, Rasmus Lerdorf wrote:
>> We have to be really really careful with this "oh, that code is wrong,
>> so we can break it argument". This will break hundreds if not thousands
>> of sites in a hard-to-debug way. It took me less than a minute of
>> looking on Github to find a case that will break:
>>
>> https://github.com/chenboking/service.downloadmanager.amule/blob/cda510415f9a58660e096a7de42b3ea6f39ee851/webserver/php-default/amuleweb-main-search.php#L121
>>
>> It is extremely common to just do a less-than or a greater-than check in
>> a user comparison function. Of course it isn't textbook-correct, but
>> since it has always worked, people do it.
>
> And just to further illustrate this, I just downloaded the current
> Wordpress release and sure enough, Wordpress would also be broken by
> this change.
>
> In http://core.svn.wordpress.org/trunk/wp-includes/class-simplepie.php
> look at the sort_items() method:
>
> /**
> * Sorting callback for items
> *
> * @access private
> * @param SimplePie $a
> * @param SimplePie $b
> * @return boolean
> */
> public static function sort_items($a, $b)
> {
> return $a->get_date('U') <= $b->get_date('U');
> }
>
> I am not saying we should revert the change, but we need to be very
> aware of the effect this change will have on PHP7 adoption. The really
> nasty part is that even if a big codebase has unit tests covering the
> code, unless the unit test actually tests an array with more than 16
> elements, all tests will pass and the application will only fail in
> production with production data. And there are no errors or warnings of
> any sort either that will help people track this down.
>
> This will need to be front and center in the UPGRADING doc with an
> explanation about how to write a proper ordering function.
hmm, maybe there is some thing I can do..
that is, we don't use >= in sorting algo, but use > and <= as condition...
which should avoid break such use cases.. I'will have a try
thanks
>
> -Rasmus
>
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
On Sun, Jan 18, 2015 at 3:08 PM, Rasmus Lerdorf wrote: > On 01/18/2015 11:45 AM, Stanislav Malyshev wrote: >> Hi! >> >>> Yes, like I said, I am aware that the comparison function is flaky >>> but it is still code that has worked for 15 years so we have to be >>> clear about the BC break. The fact that it works up until the array >> >> Looking at that function, I'm not sure the fact it worked is not pure >> luck. It is not an order function - it produces different result when >> parameters are switched, i.e. if you call f($a, $b) it would say $a > >> $b, but if you call f($b, $a) it would say $a == $b. Of course, even >> broken functions can produce valid results, with some luck, but I'm not >> sure we can guarantee non-order functions to work when order function is >> required. > > Sure, I understand it is flaky. But it is still code that has always > worked in every single version of PHP (and HHVM) ever released going > back 15+ years. > > eg. http://3v4l.org/7prWJ > > and I have a php3 build here that it works on as well. > > We have to be really really careful with this "oh, that code is wrong, > so we can break it argument". This will break hundreds if not thousands > of sites in a hard-to-debug way. It took me less than a minute of > looking on Github to find a case that will break: > > https://github.com/chenboking/service.downloadmanager.amule/blob/cda510415f9a58660e096a7de42b3ea6f39ee851/webserver/php-default/amuleweb-main-search.php#L121 > > It is extremely common to just do a less-than or a greater-than check in > a user comparison function. Of course it isn't textbook-correct, but > since it has always worked, people do it. I have no qualms about breaking code that is not even returning the correct type when the documentation explains how it is supposed to work[1]. The integer value returned by a comparison function is not even boolean-like, which means that using < or <= is fundamentally incorrect. With that said, I'm not sure the kind of performance numbers being reported are worth changing the behavior. I haven't looked at the patch, but if the code isn't cleaner or more maintainable then I'd have to say that the performance numbers alone really aren't worth changing the code. [1] At least on the pages I checked, such as usort and uksort -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
Hey:
Rasmus, Thanks for the reporting... I didn't think it is a real
reasonable question at the very beginning
Anyway, this should be fixed in :
https://github.com/php/php-src/commit/020b51b46eceb1a8c2876aac263772ed55ba9a1a
thanks
On Mon, Jan 19, 2015 at 2:06 PM, Xinchen Hui wrote:
> Hey:
>
> On Mon, Jan 19, 2015 at 12:52 PM, Rasmus Lerdorf wrote:
>> On 01/18/2015 02:08 PM, Rasmus Lerdorf wrote:
>>> We have to be really really careful with this "oh, that code is wrong,
>>> so we can break it argument". This will break hundreds if not thousands
>>> of sites in a hard-to-debug way. It took me less than a minute of
>>> looking on Github to find a case that will break:
>>>
>>> https://github.com/chenboking/service.downloadmanager.amule/blob/cda510415f9a58660e096a7de42b3ea6f39ee851/webserver/php-default/amuleweb-main-search.php#L121
>>>
>>> It is extremely common to just do a less-than or a greater-than check in
>>> a user comparison function. Of course it isn't textbook-correct, but
>>> since it has always worked, people do it.
>>
>> And just to further illustrate this, I just downloaded the current
>> Wordpress release and sure enough, Wordpress would also be broken by
>> this change.
>>
>> In http://core.svn.wordpress.org/trunk/wp-includes/class-simplepie.php
>> look at the sort_items() method:
>>
>> /**
>> * Sorting callback for items
>> *
>> * @access private
>> * @param SimplePie $a
>> * @param SimplePie $b
>> * @return boolean
>> */
>> public static function sort_items($a, $b)
>> {
>> return $a->get_date('U') <= $b->get_date('U');
>> }
>>
>> I am not saying we should revert the change, but we need to be very
>> aware of the effect this change will have on PHP7 adoption. The really
>> nasty part is that even if a big codebase has unit tests covering the
>> code, unless the unit test actually tests an array with more than 16
>> elements, all tests will pass and the application will only fail in
>> production with production data. And there are no errors or warnings of
>> any sort either that will help people track this down.
>>
>> This will need to be front and center in the UPGRADING doc with an
>> explanation about how to write a proper ordering function.
> hmm, maybe there is some thing I can do..
>
> that is, we don't use >= in sorting algo, but use > and <= as condition...
>
> which should avoid break such use cases.. I'will have a try
>
> thanks
>>
>> -Rasmus
>>
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PEAR and make install on master
Hi! > Fatal error: Non-static method PEAR_Installer_Role::initializeConfig() > cannot be called statically, assuming $this from incompatible context in > phar:///.../pear/install-pear-nozlib.phar/PEAR/Config.php on line 599 > make[1]: *** [install-pear-installer] Error 255 > make: *** [install-pear] Error 2 > > I've tried to look up the pear MLs, but I haven't seen any recent > activity... what's the plan, if any? Can't we just fix it? As I understand, it's just making this: function initializeConfig(&$config) into this: static function initializeConfig(&$config) In PEAR/Installer/Role.php but I'm not sure where to commit the patch or how to get it into phars (they don't seem to be the latest code in git). Anybody knows what's the right way here? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Preserve Fractional Part in JSON encode
Hi! > I do not know who are the "people" but the release process is pretty > clear on that. We decided not to allow features additions to ease > developers life, like not having to do dozen of tests to know which > minor versions added what. It is also why we have yearly releases, We have always added small features in patch versions. Just look in the UPGRADING or NEWS. E.g: 5.6.5: . Fixed bug #68479 (Added escape parameter to SplFileObject::fputcsv). (Salathe) 5.6.3: . Implemented gmp_random_range() and gmp_random_bits(). (Leigh) 5.6.1: . Implemented gmp_import() and gmp_export(). (Leigh, Nikita) I'm pretty sure there is more in 5.5. I don't see how suddenly it is not allowed. This is an option addition, something that always was OK in patch versions. Or do you see some other concern that I miss here? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Remove deprecated functionality in PHP 7
> Il giorno 16/gen/2015, alle ore 18:16, Nikita Popov ha > scritto: > > I'll land the minor removals sometime soon; the unbundling of ext/ereg and > ext/mysql should probably be done by someone else who's more into the PECL > business. I can take care of the PDO::PGSQL constant, if you’d like. Cheers — Matteo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class constructor behaviour
On 19 January 2015 at 05:48, Stanislav Malyshev wrote:
> Hi!
>
> > A constructor that fails is a hard failure (factory method failed to
> > produce the expected value), and is an exceptional case that can or
> cannot
> > be handled (via catch).
> > It's not just a failed operation (expected to eventually fail), but
> > something really went wrong, badly.
>
> Why it is different from any other failure? I.e. fopen("doesnotexist",
> "r") produces false and it's not "hard failure". But if files were
> objects, new File("doesnotexist", File::READONLY) suddenly becomes "hard
> failure"? How the latter is harder than the former? I would say it's
> exactly the same. If you say "new File" can only throw, you should also
> say fopen() should only throw. If fopen can return error value, so can
> File::open(), so can new File.
>
Excerpt from SplFileObject's manual page [1]:
Throws a RuntimeException if the filename cannot be opened.
[1] http://php.net/splfileobject.construct
> The difference would be if File object would be built so that "new File"
> should never fail, and opening would be done with "$file->open()" and
> not with the ctor. But most of the object APIs in PHP are not written
> this way - for these APIs, ctor failure is not something exceptional
> more than failing to open file is exceptional.
>
> > Additionally, it makes no sense to have inconsistent behavior between
> > internal classes and userland classes: it is currently impossible for a
> > userland class to have the `new` operator producing an object that is not
> > an instance of the class after that operator.
>
> That can be changed if needed. This is just a missing feature.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
