> On 02/18/2016 02:10 PM, Colin O'Dell wrote:
>>
>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>> keyword.
>
I'm tepidly +1 this. It's not hurting anything, but var's time has
past. Let's deprecate it, and in four year's time as we're starting
to talk PHP8, we can ask
Hi!
> Although it is true that an upgrade from PHP 7 to 8 will involve more
> work, it is not true that it does not hurt anyone. This is a well
> known problem in design:
>
> https://www.nngroup.com/articles/reduce-redundancydecrease-duplicated-de
> sign-decisions/
This is all generic advice whic
Hi,
Le 18/02/2016 20:10, Colin O'Dell a écrit :
Hello everyone,
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
My understanding is that this keyword was kept in PHP 5 for
backwards-compatibility with PHP 4. However, it's been 9 years since PHP 4
was discontin
Le 19/02/2016 00:48, Andrea Faulds a écrit :
You might have to make yet another post. This last one had a new
subject, but it still was marked as a reply, so my news client threads
it in with the original thread.
Just posted the message once again. Still appears in the same thread. It
seems
Hi,
Starting vote about : https://wiki.php.net/rfc/negative-string-offsets
Voting period ends Friday, March 4th 00:00 UTC.
As, during the discussion, we talked about many related subjects, please
remember that the subjects below remain out of scope of this RFC and
deserve their own thread :
On Thu, Feb 18, 2016 at 11:45 PM, Zeev Suraski wrote:
> > With rand functions, I don't think we need to touch them. For some
> > applications, low-key randomness is just fine - if you need to shuffle
> > array of 20 elements or randomize unit test to ensure you're not testing
> > same value all t
Hi,
PHP 7.0.4 RC1 was just released and can be downloaded from:
https://downloads.php.net/~ab/
The Windows binaries are available at
http://windows.php.net/qa/
This release contains a number of bugfixes.
For the list of bugfixes that you can target in your testing, please refer
to the
Hi François,
François Laupretre wrote:
(sorry, posting again with modified subject to force new thread)
You might have to make yet another post. This last one had a new
subject, but it still was marked as a reply, so my news client threads
it in with the original thread.
On a different not
>
> By the time of 8.0 nothing would be different from today. 8.0 is not
> some magic number by which old code ceases to exist.
>
The usage of "var" may continue to decline as folks increasingly adopt the
newer visibility keywords. Perhaps it's too early to make this decision
and this discussion
>
> It would have to be done in 8.0, since removing it would constitute a BC
> break.
>
Thanks for clarifying that Tom! Makes sense to me.
> It's worth noting that there were better reasons for deprecating PHP
> 4-style constructors over the simple redundancy argument. Specifically,
> there was
Hi Zeev,
Zeev Suraski wrote:
On 18 בפבר׳ 2016, at 21:58, Andrea Faulds wrote:
Hmm. Well, if we're doing mass deprecations, maybe we should finally get rid of
hebrev() and hebrevc()? It feels out-of-place to have a poorly-documented
standard library function specifically for converting bet
Hi!
> But is there a strong reason to keep it forever, especially considering its
Yes. It's the same reason - "no reason to remove". When we have action
which on one hand has no tangible benefit and on the other hand has
tangible harm, we should not do it.
> decline in usage? Perhaps by targeti
>
> I think it's a drop in the bucket compare to new features we're adding
> plenty of on every version. These make the language a lot more complex
> than var being an alias to public (not even different syntax).
>
Very true. I'm not proposing this because it's a great new feature. But has
this l
Hi!
> I do have a general question about these types of changes: if the
> deprecation were to land in 7.1, when would the actual removal take place -
> 7.2 or 8.0? Or would that be a voting option?
It would have to be done in 8.0, since removing it would constitute a BC break.
It's worth noting
Hi!
>> Hmm. Well, if we're doing mass deprecations, maybe we should finally get rid
>> of
I must note that I think this drive to "get rid of" functions that does
not stand in anybody's way (as opposed to the case of __autoload which
is incompatible with superior stackable autoloader solution) is
> On 18 בפבר׳ 2016, at 23:23, Yasuo Ohgaki wrote:
>
> Hi all,
>
>> On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote:
>>
>> Colin O'Dell wrote:
>>>
>>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>>> keyword.
>>
>>
>> I don't have a strong opinion on that, I
> On 18 בפבר׳ 2016, at 21:58, Andrea Faulds wrote:
>
>
> Hmm. Well, if we're doing mass deprecations, maybe we should finally get rid
> of hebrev() and hebrevc()? It feels out-of-place to have a poorly-documented
> standard library function specifically for converting between two different
>
Hi!
> Although it is true that an upgrade from PHP 7 to 8 will involve more
> work, it is not true that it does not hurt anyone. This is a well
> known problem in design:
>
> https://www.nngroup.com/articles/reduce-redundancydecrease-duplicated-de
> sign-decisions/
This is all generic advice whi
> On 18 בפבר׳ 2016, at 23:42, Stanislav Malyshev wrote:
>
> Hi!
>
>> I've created a bulk-deprecation RFC for PHP 7.1:
>> https://wiki.php.net/rfc/deprecations_php_7_1
>
> I like dropping php_errormsg. Last time I tried to make error
> suppression work more efficiently this was a major problem
> Though if we do get rid of the var syntax, I'd like it if we kept the
> reserved word, because it still might be useful in future for typed
> variables or different variable scoping.
Good idea Andrea! Thanks for that suggestion.
I do have a general question about these types of changes: if the
> On 18 בפבר׳ 2016, at 14:42, Nikita Popov wrote:
>
> Hi internals!
>
> I've created a bulk-deprecation RFC for PHP 7.1:
> https://wiki.php.net/rfc/deprecations_php_7_1
>
> I'm using this RFC to collect various deprecations targeting PHP 7.1, as
> having individual RFCs for these is too much m
Hi!
> I've created a bulk-deprecation RFC for PHP 7.1:
> https://wiki.php.net/rfc/deprecations_php_7_1
>
I like dropping php_errormsg. Last time I tried to make error
suppression work more efficiently this was a major problematic thing
AFAIR, and in general using magic variables that pop out of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/18/2016 10:32 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I'd like to propose an RFC to deprecate and eventually remove the
>> "var" keyword.
>
> Don't see much point - it is the same as public and doesn't hurt
> anyone. Removing it does not impr
Hi!
> I'd like to propose an RFC to deprecate and eventually remove the "var"
> keyword.
Don't see much point - it is the same as public and doesn't hurt anyone.
Removing it does not improve any code in any way, just makes it harder
to upgrade.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Inte
Hi all,
On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote:
>
> Colin O'Dell wrote:
>>
>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>> keyword.
>
>
> I don't have a strong opinion on that, I guess I'm in favour. It seems like
> a fairly harmless deprecation.
>
> Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/18/2016 9:58 PM, Colin O'Dell wrote:
>> What are your reasons for this proposal?
>>
>> I can think of multiple reasons why this might not be a good
>> idea, but the only reason that pops to mind for getting rid of it
>> is to make PHP work like
On Wed, Feb 17, 2016 at 2:05 PM, Kevin Gessner wrote:
> On Wed, Feb 17, 2016 at 9:25 AM, Kevin Gessner wrote:
>
>> Hello internals team! I'd like to propose an RFC to allow traits to
>> implement interfaces.
>>
>
> I've created a proper RFC wiki page here with the draft:
> https://wiki.php.net/
> What are your reasons for this proposal?
>
> I can think of multiple reasons why this might not be a good idea, but the
> only reason that pops to mind for getting rid of it is to make PHP work
> like a different style of language.
I'm proposing this change because it will remove duplicate funct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/18/2016 8:57 PM, Andrea Faulds wrote:
>
> Nikita Popov wrote:
>> https://wiki.php.net/rfc/deprecations_php_7_1
>
> I've actually used create_function on occasion for
> programmatically generating functions (in particular to create a
> function
On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann
wrote:
> On 02/18/2016 02:10 PM, Colin O'Dell wrote:
>
>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>> keyword.
>>
>
> +1
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http
Hi Nikita,
Nikita Popov wrote:
I've created a bulk-deprecation RFC for PHP 7.1:
https://wiki.php.net/rfc/deprecations_php_7_1
I'd be fine with getting rid of all of the ones suggested so far
(__autoload, $php_errormsg, create_function, rand/srand).
I've actually used create_function on occa
Nikita Popov wrote on 18.02.2016 13:41:
> Hi internals!
>
> I've created a bulk-deprecation RFC for PHP 7.1:
> https://wiki.php.net/rfc/deprecations_php_7_1
>
> I'm using this RFC to collect various deprecations targeting PHP 7.1, as
> having individual RFCs for these is too much management over
Hi Colin,
Colin O'Dell wrote:
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
I don't have a strong opinion on that, I guess I'm in favour. It seems
like a fairly harmless deprecation.
Though if we do get rid of the var syntax, I'd like it if we kept the
re
-1 (minus one)
Very best regards,
Kubis Pandian-Fowler
Od: Sebastian Bergmann
Odoslané: piatok, 19. februára 2016 1:00
Komu: internals@lists.php.net
On 02/18/2016 02:10 PM, Colin O'Dell wrote:
> I'd like to propose an RFC to deprecate and eventually remove the "var"
> key
On 02/18/2016 02:10 PM, Colin O'Dell wrote:
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Feb 18, 2016 at 1:29 PM Nikita Popov wrote:
> On Wed, Feb 17, 2016 at 3:25 PM, Kevin Gessner wrote:
>
> > Hello internals team! I'd like to propose an RFC to allow traits to
> > implement interfaces.
> >
> > I've noticed s pattern in Etsy's code and elsewhere, where a trait
> provides
>
Hello everyone,
I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.
My understanding is that this keyword was kept in PHP 5 for
backwards-compatibility with PHP 4. However, it's been 9 years since PHP 4
was discontinued, so I'd like to bring this topic up for review.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/18/2016 7:28 PM, Nikita Popov wrote:
>
> Without given an opinion on the RFC itself, this might be
> interesting for context:
>
> http://hhvm.com/blog/9581/trait-and-interface-requirements-in-hack
>
> HHVM already supports "trait Foo implemen
On Wed, Feb 17, 2016 at 3:25 PM, Kevin Gessner wrote:
> Hello internals team! I'd like to propose an RFC to allow traits to
> implement interfaces.
>
> I've noticed s pattern in Etsy's code and elsewhere, where a trait provides
> a common implementation of an interface. Classes that use the tra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
First off: I like the idea of a trait being able to implement an
interface and having PHP validating that because I am like Larry and
prefer language construct over comments.
On 2/18/2016 4:11 PM, Chase Peeler wrote:
>
> I agree, in theory, but I a
> -Original Message-
> From: Anatol Belski [mailto:anatol@belski.net]
> Sent: Thursday, February 18, 2016 7:00 PM
> To: 'Côme Chilliet'
> Subject: RE: php-ldap pull request
>
> Hi Côme,
>
> > -Original Message-
> > From: Côme Chilliet [mailto:c...@opensides.be]
> > Sent: We
On Wed, Feb 17, 2016 at 6:13 PM, Levi Morrison wrote:
> On Wed, Feb 17, 2016 at 12:48 PM, Kevin Gessner wrote:
> > I don't think there is enough benefit from allowing traits to declare
> > interfaces, but not propagating the interface out to classes that insert
> the
> > trait. It does provide
Hi Chase and Larry,
On Thu, Feb 18, 2016 at 10:11 AM, Chase Peeler
wrote:
> On Thu, Feb 18, 2016 at 5:35 AM Larry Garfield
> wrote:
> I'd rather the class
> > still need to self-declare the interface; that it uses a trait to
> > fulfill that contract is irrelevant to the outside world.
> >
> I
On Thu, Feb 18, 2016 at 5:35 AM Larry Garfield
wrote:
> On Wed, Feb 17, 2016, at 01:05 PM, Kevin Gessner wrote:
> > On Wed, Feb 17, 2016 at 9:25 AM, Kevin Gessner
> wrote:
> >
> > > Hello internals team! I'd like to propose an RFC to allow traits to
> > > implement interfaces.
> > >
> >
> > I'v
Hi,
(sorry, posting again with modified subject to force new thread)
Starting vote about : https://wiki.php.net/rfc/negative-string-offsets
Voting period ends Friday, March 4th 00:00 UTC.
As, during the discussion, we talked about many related subjects, please
remember that the subjects below
Hi,
Starting vote about : https://wiki.php.net/rfc/negative-string-offsets
Voting period ends Friday, March 4th 00:00 UTC.
As, during the discussion, we talked about many related subjects, please
remember that the subjects below remain out of scope of this RFC and
deserve their own thread :
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: Thursday, February 18, 2016 2:42 PM
> To: PHP internals
> Subject: [PHP-DEV] [RFC] Deprecations for PHP 7.1
>
> Hi internals!
>
> I've created a bulk-deprecation RFC for PHP 7.1:
> https://wiki.php.net/rfc/de
Hi internals!
I've created a bulk-deprecation RFC for PHP 7.1:
https://wiki.php.net/rfc/deprecations_php_7_1
I'm using this RFC to collect various deprecations targeting PHP 7.1, as
having individual RFCs for these is too much management overhead. Each
deprecated feature will get its own vote, of
Results for project PHP master, build date 2016-02-18 06:31:37+02:00
commit: 030b7ba
previous commit:3244d3c
revision date: 2016-02-18 00:32:48+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Wed, Feb 17, 2016, at 01:05 PM, Kevin Gessner wrote:
> On Wed, Feb 17, 2016 at 9:25 AM, Kevin Gessner wrote:
>
> > Hello internals team! I'd like to propose an RFC to allow traits to
> > implement interfaces.
> >
>
> I've created a proper RFC wiki page here with the draft:
> https://wiki.php
Hi Christian,
> -Original Message-
> From: Christian Schneider [mailto:cschn...@cschneid.com]
> Sent: Wednesday, February 17, 2016 2:07 PM
> To: PHP internals
> Subject: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion
>
> Hi there,
> we just ran into a version of the bug "JIT
51 matches
Mail list logo
