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 ev
> 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.
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
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-pea
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:
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
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
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 d
> 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
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
> 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
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
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
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 tha
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.inte
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
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 -
esp
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
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,
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.
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 cas
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, Ya
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_com
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, JS
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 pa
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 "peo
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 any
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 Fr
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:
>> >
>> >>
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
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/php
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 ad
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
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
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 alread
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-ch
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
> 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();
"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
"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 towa
"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/manua
"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 constructo
"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 (f
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 pr
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
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.
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
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
48 matches
Mail list logo
