Hi,
On Jan 18, 2015 9: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
Morning Sara,
Great idea, +1, also agree that it doesn't really need an RFC ... but
I'm always wrong ...
Cheers
Joe
On Sun, Jan 18, 2015 at 2: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
> De : Andrea Faulds [mailto:a...@ajf.me]
>
> 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 except
Rasmus,
> _ is not really an option since it is the standard gettext() shortcut.
Yup, Simon J. pointed that out too so usage of `_` was already a discarded
topic.
The top topic now is a possible consistency with the syntax already allowed
when using list. Ex:
list($bar, , $baz) = ['good', 'trash
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 ta
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?
On Jan 17, 2015, at 17:52, Marcio Almada wrote:
>> Cryptic notation is not a PHP way. IMHO.I like original "default" proposal
>> and it is good enough.
>> Regards,
>
> When I suggested `_` it was more as a feature wandering. I like
> `default` too. The RFC looks good enough as it is now :)
_ i
Hey Marcio,
> On 18 Jan 2015, at 02:22, Marcio Almada wrote:
>
> Andrea,
>
>> For consistency with list(), we could also just put nothing:
>>
>> foo($bar, , $baz);
>>
>> Which is like:
>>
>> list($bar, , $baz) = $arr;
>>
>> Thoughts?
>
> Not sure. Do we consider both contexts (list assi
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
ind
Andrea,
> For consistency with list(), we could also just put nothing:
>
>foo($bar, , $baz);
>
> Which is like:
>
> list($bar, , $baz) = $arr;
>
> Thoughts?
Not sure. Do we consider both contexts (list assignment skipping and
parameter skipping) as assignments? If so, then the consistency
a
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.
Hi Marcio,
> On 18 Jan 2015, at 02:01, Marcio Almada wrote:
>
> Just a note:
>
> I still think a single char token (like `~`) would look great and
> wouldn't be "cryptic" like Yasuo argued. But, as said before, it's
> just a minor observation. The `default` token is a great option and
> sounds
Just a note:
I still think a single char token (like `~`) would look great and
wouldn't be "cryptic" like Yasuo argued. But, as said before, it's
just a minor observation. The `default` token is a great option and
sounds very intuitive to anyone I've asked for opinions.
2015-01-17 22:52 GMT-03:00
> Cryptic notation is not a PHP way. IMHO.I like original "default" proposal
> and it is good enough.
> Regards,
When I suggested `_` it was more as a feature wandering. I like
`default` too. The RFC looks good enough as it is now :)
2015-01-17 22:14 GMT-03:00 Yasuo Ohgaki :
> Hi all,
>
> On Fri
On 17 January 2015 at 16:37, François Laupretre
wrote:
> > De : Dan Ackroyd [mailto:dan...@basereality.com]
> >
> > This is pretty horrible and should be fixed by making sure that
> > constructors either return an object or throw an exception.
> > Additionally the exception policy for core (that
Hi all,
On Fri, Jan 16, 2015 at 7:29 PM, Patrick Schaaf wrote:
> Am 14.01.2015 20:50 schrieb "Simon J Welsh" :
> >
> > >create_query("deleted=0", "name", _, _, true);
> > >
> > > Still not sure if it's better than `default`, though.
> >
> > That would be a BC break as you can currently have
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
> ze
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-s
On 11/01/2015 04:02, Juan Basso wrote:
I'd like to initiate a vote on this RFC:
https://wiki.php.net/rfc/json_preserve_fractional_part
Hi,
After discussing this RFC with other people of AFUP, we are +1 on this.
Being able to get back the same PHP type after encoding data to JSON and
re-deco
Hey Rowan,
> On 17 Jan 2015, at 19:40, Rowan Collins wrote:
>
> 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 wor
Hi internals!
The RFC proposing to remove support for hexadecimal strings in
is_numeric_string() is now in voting:
https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings
Thanks,
Nikita
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 b
Hi,
If this patch is accepted: https://github.com/php/php-src/pull/1001
Should the few checks that are made before it is called be removed?
For example, in the /ext/phar/phar.c file:
1206if (error) {
1207spprintf(error, 0, "internal error: attempt to
flus
On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth wrote:
> On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote:
>> >> 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 poi
Hi!
Since it’s been a week and there have been no objections, I’ve merged the octal
fix patch into php master:
https://github.com/php/php-src/commit/5f29b980514867f1a09969ca6a1c1f5fb00c3027
Finally, it is fixed after all these years :)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP
On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote:
> >> 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
>> 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 t
On 17 January 2015 at 16:04, Rowan Collins wrote:
> The difference is that AFAIK all the exceptions returned by OOP extensions
> right now are of classes specific to that extension, whereas this would be a
> global engine-thrown exception.
Sorry - I wasn't clear. I didn't mean they should throw
On 17 January 2015 at 15:43, Andrea Faulds wrote:
> 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
On 17 January 2015 at 13:38, César Rodas wrote:
> Hi Pierre!
>
> On 17/01/15 08:02, Pierre Joye wrote:
> > On Jan 17, 2015 5:58 PM, "Tony Marston" wrote:
> >>
> >> "Stelian Mocanita" wrote in message
> >> news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com.
> ..
> >>>
> >>>
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 er
> De : Dan Ackroyd [mailto:dan...@basereality.com]
>
> This is pretty horrible and should be fixed by making sure that
> constructors either return an object or throw an exception.
> Additionally the exception policy for core (that was previously
> discussed here: http://marc.info/?t=1192637480
On Jan 17, 2015 7:22 PM, "Andrea Faulds" wrote:
>
> Hey Pierre,
>
> > On 17 Jan 2015, at 05:56, Pierre Joye wrote:
> >
> > It looks to me like yet another can of worms (how do you deal with
> > conversions, mixed operations, etc. it adds a lot of special cases)
> > with little benefits.
>
> The c
Hi,
I've been going through some bug reports, and have found there are
several bad behaviours related to class constructors that ought to be
corrected, but could only be done at a major version. The bad
behaviours are:
Constructors returning null
---
Several classes in PH
Hi Pierre!
On 17/01/15 08:02, Pierre Joye wrote:
> On Jan 17, 2015 5:58 PM, "Tony Marston" wrote:
>>
>> "Stelian Mocanita" wrote in message
>> news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com...
>>>
>>>
>>> Florian Margaine wrote on 16/01/2015 13:01:
>>>
>>> Hi Stelian,
>>
Hey Pierre,
> On 17 Jan 2015, at 05:56, Pierre Joye wrote:
>
> It looks to me like yet another can of worms (how do you deal with
> conversions, mixed operations, etc. it adds a lot of special cases)
> with little benefits.
The conversions are trivial and there are no operations to implement. T
On 16 January 2015 at 21:15, Yasuo Ohgaki wrote:
> Hi Rowan,
>
> On Sat, Jan 17, 2015 at 1:22 AM, Rowan Collins
> wrote:
>
>> Yasuo Ohgaki wrote on 16/01/2015 08:40:
>>
>>> Hi all,
>>>
>>> Take a look at
>>>
>>> http://3v4l.org/HbVnd
>>>
>>> foreach should not affect internal(zval) array positio
On 16.01.2015 09:00, Matteo Beccati wrote:
> On 15/01/2015 22:16, Ralf Lang wrote:
>> On 15.01.2015 21:35, Mike wrote:
>>> Wouldn't this one change render all code in PEAR as broken?
>> No.
>
> Why not? PEAR uses PHP4-constructors almost everywhere.
A lot of pear packages don't use custom constru
On Jan 17, 2015 5:58 PM, "Tony Marston" wrote:
"Stelian Mocanita" wrote in message
news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com...
Florian Margaine wrote on 16/01/2015 13:01:
Hi Stelian,
Stelian Mocanita writes:
Not under active development doesn't mean tha
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Freitag, 16. Januar 2015 21:35
> An: Robert Stoll; 'Marc Bennewitz'; internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] [RFC] Skipping parameters take 2
>
> Hi!
>
> > This would be quite a nic
On Jan 17, 2015 5:58 PM, "Tony Marston" wrote:
>
> "Stelian Mocanita" wrote in message
> news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com...
>>
>>
>> Florian Margaine wrote on 16/01/2015 13:01:
>>
>> Hi Stelian,
>>>
>>>
>>> Stelian Mocanita writes:
>>>
>>> Not under active
"Stelian Mocanita" wrote in message
news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com...
Florian Margaine wrote on 16/01/2015 13:01:
Hi Stelian,
Stelian Mocanita writes:
Not under active development doesn't mean that the application shouldn't
be able to upgrade PHP and
On 17/01/15 20:38, Joshua Rogers wrote:
> This will probably be fixed in a few hours, but I'm unable to build from
> master, in the git repo, due to this commit:
> https://github.com/php/php-src/commit/ebb60ac7dd179a3bea540d50a7d595010a82a656#diff-fb329ac450d632c19d4cde46b4e9a38eR1008
>
> ext/intl/
On 17/01/15 05:54, Pierre Joye wrote:
>> > Andrea Faulds has kindly written a utility that identifies when a PHP
>> > 4 constructor is defined[2]. It does not automatically change the code
>> > for liability reasons. The utility PHPMD[3] can also detect this but
>> > has a false positive when `__co
This will probably be fixed in a few hours, but I'm unable to build from
master, in the git repo, due to this commit:
https://github.com/php/php-src/commit/ebb60ac7dd179a3bea540d50a7d595010a82a656#diff-fb329ac450d632c19d4cde46b4e9a38eR1008
ext/intl/.libs/php_intl.o: In function `zm_startup_intl':
45 matches
Mail list logo
