Hi!
> My proposal is to deprecate the use of var on properties in PHP 7, and then
> remove support for it in PHP 8. This compliments the [0] "Remove PHP 4
How the life of the PHP user would be improved by this? Except for
making more code break, I'm not sure how it's helpful, could you explain?
Hi!
> there should be no bc break as the API doesn't change and the method
> produces the exact same result as before.
Sorry, this makes no sense to me. You claim that if you changed the
method code to do different thing it should continue working as if you
didn't change it? Why? I just don't get
On 12/02/15 19:55, Thomas Punt wrote:
> I'd like to propose to make empty() a variadic, where if any
> arguments passed in are considered empty, then false is returned
Should that read "if any arguments passed in are considered *NOT* empty,
then false is returned"?
--
Regards,
Mike
--
PHP In
Hi,
Le Thu, 12 Feb 2015 19:55:09 +0100, Thomas Punt a
écrit:
Hello PHP Internals!
I'd like to propose to make empty() a variadic, where if any arguments
passed in are considered empty, then false is returned - otherwise
return true.
I absolutely love this idea, and would make a good us
W dniu 2015-02-12 o 19:55, Thomas Punt pisze:
Hello PHP Internals!
I'd like to propose to make empty() a variadic, where if any arguments passed
in are considered empty, then false is returned - otherwise return true.
My reasoning for wanting this feature is as follows:1)It's a common scenario t
Hi!
> Such code will break, not in the first place but later on!
Later on when?
> You propose that every instance method not using the variable $this
> internally will be magically a static method and can never ever be
The difference between static method and non-static method is pretty
much th
Hi Nikita,
On Thu, Feb 12, 2015 at 11:24 PM, Nikita Popov wrote:
> Any objections to implement the incompatible context removal this way?
It was long time question for me allowing the code you would like to remove.
If these are removed altogether(make them illegal), it would be good for
users
Hi Stas,
Am 12.02.2015 um 22:31 schrieb Stanislav Malyshev:
Hi!
class A {
// This is an *instance* method, but it doesn't actually use $this.
// This kind of usage is very common in PHP 4 era code, where
// "static" annotations weren't used
function test() {
echo "
Hi Marcio,
I send this because use of array operator has some popularities at least.
On Thu, Feb 12, 2015 at 11:25 PM, Marcio Almada
wrote:
> > Yup sure. We are going to vote yes (behind my nickname).
> > However, while I agree with all your arguments, we have more syntax and
> more semantics,
Hi Pierre,
On Fri, Feb 13, 2015 at 6:36 AM, Pierre Joye wrote:
> On Fri, Feb 13, 2015 at 3:51 AM, Yasuo Ohgaki wrote:
> > Hi all,
> >
> > On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev
> wrote:
> >
> >> On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano
> >> wrote:
> >> > On 09/02/2015 22:29,
Hi Derick,
I came across with strange DataTime generates legal date from illegal date.
http://3v4l.org/rKFIg
format('Y-m-d H:i:s'));
$date = new DateTime('-01-00');
var_dump($date->format('Y-m-d H:i:s'));
$date = new DateTime('-00-01'); // "-0001-12-01 00:00:00" legal date
from illegal da
Hi,
> I like use Foo\Bar\(Baz, Qux);
> For Human type experience, {} is harder than () to type, see your
> keyboard, can you easier type {} or easier type ()
> I hate {}
> If you like to use {} as the group symbols, i would not like it.
> It hurts my fingers.
Your suggested syntax was cons
Hi,
2015-02-13 1:33 GMT+01:00 Netroby :
> For Human type experience, {} is harder than () to type, see your
> keyboard, can you easier type {} or easier type ()
That depends on your keyboard and its configuration and might not be
true for the majority of php users.
> I hate {}
>
> If you like t
For Human type experience, {} is harder than () to type, see your
keyboard, can you easier type {} or easier type ()
I hate {}
If you like to use {} as the group symbols, i would not like it.
It hurts my fingers.
Appreciate your time.
Netroby
2015-02-12 17:55 GM
I like use Foo\Bar\(Baz, Qux);
Appreciate your time.
Netroby
2015-02-12 17:55 GMT+08:00 Ivan Enderlin @ Hoa :
> Hi Marcio,
>
> Thanks for the RFC!
> We discussed a little bit with the Hoa [1]'s and fruux [2]'s community and
> we have a question. Why not pretending
On Fri, Feb 13, 2015 at 12:13 AM, Marcio Almada
wrote:
> Hi Stellan,
>
> >Hello Marcio,
> > I am inclined to vote no for a couple of reasons:
>
> > 1. This is not a BC-break, I would move the vote to PHP 7.1. The
> reasoning behind this is that the tools in the ecosystem will have a lot
> > of wo
On Fri, Feb 13, 2015 at 12:06 AM, Ferenc Kovacs wrote:
> adding the E_DEPRECATED was only about the assuming $this behavior:
> https://wiki.php.net/rfc/incompat_ctx
>
While the RFC may claim that, the way it was implemented will throw
E_DEPRECATED irregardless whether $this is used or not. As su
Hi Stellan,
>Hello Marcio,
> I am inclined to vote no for a couple of reasons:
> 1. This is not a BC-break, I would move the vote to PHP 7.1. The
reasoning behind this is that the tools in the ecosystem will have a lot
> of work to get on par with PHP 7 (talking here about stuff like phpmd,
phpcp
On Thu, Feb 12, 2015 at 9:20 PM, Nikita Popov wrote:
> On Thu, Feb 12, 2015 at 5:45 PM, Rowan Collins
> wrote:
>
> > Nikita Popov wrote on 12/02/2015 14:24:
> >
> >> Hi internals,
> >>
> >> As part of [1] and [2] we have decided to remove support for doing
> static
> >> calls to instance methods
Thanks for the confirmation!
On Friday, February 13, 2015, Rasmus Lerdorf wrote:
> On 02/12/2015 01:39 PM, Jacob Bednarz wrote:
> > Hi Internals,
> >
> > Late in January Rasmus sent out an email to test the PHP 7 build. I've
> > recently completed this with a few of our applications locally how
On 02/12/2015 01:39 PM, Jacob Bednarz wrote:
> Hi Internals,
>
> Late in January Rasmus sent out an email to test the PHP 7 build. I've
> recently completed this with a few of our applications locally however
> now I am looking to test these changes on one of our isolated
> development environmen
Hello Marcio,
I am inclined to vote no for a couple of reasons:
1. This is not a BC-break, I would move the vote to PHP 7.1. The reasoning
behind this is that the tools in the ecosystem will have a lot of work to
get on par with PHP 7 (talking here about stuff like phpmd, phpcpd, phploc,
newrelic
Hello François,
> For a set of 'extended' types like 'number', and their matching rules against
> zvals, this may help :
>
> https://wiki.php.net/rfc/dbc#dbc_types_vs_zval_types
I did not follow the DoC-discussion so far but from a quick glance at
the list there are at least cases that need a f
On Thu, Feb 12, 2015 at 8:53 AM, Rowan Collins
wrote:
> François Laupretre wrote on 12/02/2015 14:56:
>
>> Sorry to get off-topic but could we raise the 'undefined variable' error
>> to E_WARNING, at least ? E_NOTICE seems very low for such an error.
>>
>
> I think the division between E_NOTICE a
Hi!
> It was always an E_STRICT error to call a non-static method statically
> (as usual, not counting scoped calls) and since PHP 5.6 it was
> E_DEPRECATED in the most common case. I don't see why we would suddenly
> want to go back on this and make it work without any warnings.
The reason why i
Hi!
> And yes, I'm pretty sure there is intent to remove this completely in the
> future - this is just another leftover from PHP 4. The approach outlined
> here only avoids dropping support in PHP 7 already (which the original
> patch did for all practical purposes).
Why btw remove it? OK, someb
Hi Internals,
Late in January Rasmus sent out an email to test the PHP 7 build. I've
recently completed this with a few of our applications locally however now
I am looking to test these changes on one of our isolated development
environments (yes, I'm aware of the risks and willing to take t
On Thu, Feb 12, 2015 at 10:31 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > class A {
> > // This is an *instance* method, but it doesn't actually use $this.
> > // This kind of usage is very common in PHP 4 era code, where
> > // "static" annotations weren't used
> > function test()
On Thu, Feb 12, 2015 at 10:31 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > class A {
> > // This is an *instance* method, but it doesn't actually use $this.
> > // This kind of usage is very common in PHP 4 era code, where
> > // "static" annotations weren't used
> > function test()
On Fri, Feb 13, 2015 at 3:51 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev wrote:
>
>> On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano
>> wrote:
>> > On 09/02/2015 22:29, Anatol Belski wrote:
>> >>
>> >> ext/imap
>> >> ext/mcrypt
>> >> ext/pdo_dblib
>> >
Hi!
> class A {
> // This is an *instance* method, but it doesn't actually use $this.
> // This kind of usage is very common in PHP 4 era code, where
> // "static" annotations weren't used
> function test() {
> echo "foo";
> }
> }
>
> class B {
> function test2() {
Hi all,
On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev wrote:
> On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano
> wrote:
> > On 09/02/2015 22:29, Anatol Belski wrote:
> >>
> >> ext/imap
> >> ext/mcrypt
> >> ext/pdo_dblib
> >
> >
> > Sorry if this was suggested already but if those are not mai
On Thu, Feb 12, 2015 at 5:45 PM, Rowan Collins
wrote:
> Nikita Popov wrote on 12/02/2015 14:24:
>
>> Hi internals,
>>
>> As part of [1] and [2] we have decided to remove support for doing static
>> calls to instance methods, if this would result in an incompatible $this
>> variable to be used. Wh
Hi Jordi,
On Wed, February 11, 2015 11:40, Jordi Boggiano wrote:
> On 09/02/2015 22:29, Anatol Belski wrote:
>
>> ext/imap ext/mcrypt ext/pdo_dblib
>
> Sorry if this was suggested already but if those are not maintained much
> and should not be used further ideally, shouldn't we add E_DEPRECATED t
Hi Kris,
> Date: Thu, 12 Feb 2015 11:21:40 -0800
> From: kris.cr...@gmail.com
> To: tp...@hotmail.co.uk
> CC: internals@lists.php.net
> Subject: Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic
>
> I'd say go ahead and draft an RFC with all the details of your proposed
> change, then we can dis
On Thu, Feb 12, 2015 at 10:55 AM, Thomas Punt wrote:
> Hello PHP Internals!
> I'd like to propose to make empty() a variadic, where if any arguments
> passed in are considered empty, then false is returned - otherwise return
> true.
> My reasoning for wanting this feature is as follows:1)It's a c
Hello PHP Internals!
I'd like to propose to make empty() a variadic, where if any arguments passed
in are considered empty, then false is returned - otherwise return true.
My reasoning for wanting this feature is as follows:1)It's a common scenario to
want to check multiple expressions for empty
Hi François,
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@tekwire.net]
> Gesendet: Donnerstag, 12. Februar 2015 18:01
> An: 'Robert Stoll'; 'Nikita Nefedov'; 'Andrea Faulds'
> Cc: 'Pavel Kouřil'; 'PHP Internals'
> Betreff: RE: [PHP-DEV] [VOTE] Scalar Type Hints
>
François Laupretre wrote on 12/02/2015 14:56:
Sorry to get off-topic but could we raise the 'undefined variable' error to
E_WARNING, at least ? E_NOTICE seems very low for such an error.
I think the division between E_NOTICE and E_WARNING is a bit arbitrary
sometimes, but without a good defin
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Donnerstag, 12. Februar 2015 17:50
> An: Robert Stoll
> Cc: Nikita Nefedov; Pavel Kouřil; PHP Internals
> Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Hey Robert,
>
> > On 12 Feb 2015, at 16:15, Rober
Hey Robert,
> On 12 Feb 2015, at 16:15, Robert Stoll wrote:
>
> There are several programming languages which do support dynamic typing and
> method overloading somehow (Clojure, Erlang, Prolog, Cecil and certainly
> more). Most of them use a multi-method approach and I think if PHP would
>
Nikita Popov wrote on 12/02/2015 14:24:
Hi internals,
As part of [1] and [2] we have decided to remove support for doing static
calls to instance methods, if this would result in an incompatible $this
variable to be used. When applying [3] this change we found that the change
as originally inten
> -Ursprüngliche Nachricht-
> Von: Nikita Nefedov [mailto:inefe...@gmail.com]
> Gesendet: Donnerstag, 12. Februar 2015 15:54
> An: Andrea Faulds
> Cc: Pavel Kouřil; PHP Internals
> Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Hi,
>
> 2015-02-12 18:31 GMT+04:00 Andrea Faulds :
>
>
> De : Nikita Popov [mailto:nikita@gmail.com]
>
> class B {
> function test2() {
> A::test(); // Throws E_DEPRECATED
> // Followed by E_NOTICE for undefined $this variable
> }
> }
Sorry to get off-topic but could we raise the 'undefined variable' error to
E_WARNING, at
Hi,
2015-02-12 18:31 GMT+04:00 Andrea Faulds :
> Hi Pavel,
>
> > On 12 Feb 2015, at 13:48, Pavel Kouřil wrote:
> >
> > C# does have dynamic typing.
>
> No it doesn’t, it’s a statically-typed language. I don’t understand why
> you say it has dynamic typing - there is some limited dynamism in part
Finish the patch and i will apply , also ZEND_FETCH_RESOURCE2 must be
replaced with
zend_fetch_resource2 like it was done in pgsql case
https://github.com/php/php-src/commit/0d4255de30314dbfa32827e044b35543b1ae5a39
On Thu, Feb 12, 2015 at 2:42 PM, Lester Caine wrote:
> On 12/02/15 11:35, Nikit
Definitely +1 for me.
That what I proposed before. you make it happened ;-)
On 12 February 2015 at 22:25, Marcio Almada wrote:
> > Yup sure. We are going to vote yes (behind my nickname).
> > However, while I agree with all your arguments, we have more syntax and
> more semantics, it's kind of c
Hi,
>
> > 2- Lack of numeric scalar type
> > There're others, but these ones are keys to make them fully usable.
>
> A number (or numeric, or num, or some other name) type hint is something I
> plan to propose in a future, follow-up RFC.
For a set of 'extended' types like 'number', and their matc
Hi Pavel,
> On 12 Feb 2015, at 13:48, Pavel Kouřil wrote:
>
> C# does have dynamic typing.
No it doesn’t, it’s a statically-typed language. I don’t understand why you say
it has dynamic typing - there is some limited dynamism in parts, but I don’t
think it affects what we’re talking about. Dy
> Yup sure. We are going to vote yes (behind my nickname).
> However, while I agree with all your arguments, we have more syntax and
more semantics, it's kind of confusing.
> But it's a small one,
> so +1 for us.
I bet there is no way to add such a feature without adding at least a small
amount of
Hi internals,
As part of [1] and [2] we have decided to remove support for doing static
calls to instance methods, if this would result in an incompatible $this
variable to be used. When applying [3] this change we found that the change
as originally intended may be too strict. To provide an examp
On Thu, Feb 12, 2015 at 1:45 PM, Andrea Faulds wrote:
> Hi Pavel,
>
> C# also doesn’t have dynamic typing. Plus, adding overloading to an existing
> language is more difficult.
>
C# does have dynamic typing.
Adding method overloading to an existing language may be more
difficult than creating a
On 12/02/15 14:21, Marcio Almada wrote:
Thanks for the RFC!
We discussed a little bit with the Hoa [1]'s and fruux [2]'s community
and we have a question.
Why not pretending we have an array of symbols, something like:
use Foo\Bar\[Baz, Qux];
instead of
use Foo\Bar\{Baz, Qux};
This is a
> Thanks for the RFC!
> We discussed a little bit with the Hoa [1]'s and fruux [2]'s community
and we have a question.
> Why not pretending we have an array of symbols, something like:
>use Foo\Bar\[Baz, Qux];
> instead of
>use Foo\Bar\{Baz, Qux};
> This is a list vs. block debate. Whil
On 12/02/2015 13:39, Pavel Kouřil wrote:
Well, about "number" type hint. How this would work, in combination
with strict types?
function bar(float $f) {
return $f * 1.23;
}
function foo(number $x) {
return bar($x);
}
foo(1);
From my understanding, it wouldn't?
This particular exa
Hi Pavel,
> On 12 Feb 2015, at 12:39, Pavel Kouřil wrote:
>
> I don't see any problem with combination of optional parameters with
> method overloading. C# has it and it is pretty useful and works there
> without any bigger issues. Sure, the dynamic typing may be a (small)
> issue, but again, C#
On 12/02/15 11:35, Nikita Popov wrote:
> I've still got a question about the &string_arg on line 1.9 and if it
> should be changed to a string but that change needs working through the
> following code.
>
>
> Yes, this should be changed to a string. E.g. use the 'S' zpp modifier
> and
On Thu, Feb 12, 2015 at 12:44 PM, Andrea Faulds wrote:
>
> PHP already has polymorphism through its dynamic typing. I don’t see method
> overloading happening any time soon. We have optional parameters and dynamic
> typing, which all but eliminate the main needs for overloading. We’re a
> weakl
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Thursday, February 12, 2015 1:45 PM
> To: Pavel Kouřil
> Cc: guilhermebla...@gmail.com; Zeev Suraski; Rasmus Lerdorf; PHP
> Internals
> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Hi,
>
> > On 12 Feb 2015, at 07:05, Pavel Kouřil wrote:
> >
Hi Pierre,
> On 12 Feb 2015, at 11:51, Pierre du Plessis wrote:
>
> Before I create an RFC, I just want to get some feedback on a proposal, to
> deprecated the use of "var" when declaring properties on a class.
>
> This was previously deprecated in PHP 5.0.0 and the deprecation notice was
> rem
Hi all
Before I create an RFC, I just want to get some feedback on a proposal, to
deprecated the use of "var" when declaring properties on a class.
This was previously deprecated in PHP 5.0.0 and the deprecation notice was
removed in PHP 5.1.3.
My proposal is to deprecate the use of var on prop
Hi,
> On 12 Feb 2015, at 07:05, Pavel Kouřil wrote:
>
> On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds wrote:
>>
>> A number (or numeric, or num, or some other name) type hint is something I
>> plan to propose in a future, follow-up RFC.
>>
>
> wouldn't polymorphism (via method overloading)
On Wed, Feb 11, 2015 at 1:43 PM, Lester Caine wrote:
> On 10/02/15 14:31, Lester Caine wrote:
> > in interbase/ibase_blobs.c
> >
> >> zval *blob_arg, *string_arg;
> >> ibase_blob *ib_blob;
> >>
> >> RESET_ERRMSG;
> >>
> >> if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2,
On 12/02/15 10:10, Yasuo Ohgaki wrote:
>
> 1.9 +if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
> "rr", &blob_arg, &string_arg)) {
>
> I don't read the code and just curious.
> The "string_arg" isn't string? Why you specify "r" (resource)? Is it
> badly named parameter or some ki
Hi Lester,
On Wed, Feb 11, 2015 at 9:43 PM, Lester Caine wrote:
> OK I've got a patch for master, but I know that the changes are not
> complete!
>
> http://hg.lsces.org.uk/hg/php-src/rev/8ec9101f59b6
>
> I've still got a question about the &string_arg on line 1.9 and if it
> should be changed t
Hi Marcio,
Thanks for the RFC!
We discussed a little bit with the Hoa [1]'s and fruux [2]'s community
and we have a question. Why not pretending we have an array of symbols,
something like:
use Foo\Bar\[Baz, Qux];
instead of
use Foo\Bar\{Baz, Qux};
This is a list vs. block debate.
> @Zeev: I don't like being used, singling out only my blog post because it
> proves your opinion, where clearly there were other posts in favour of
> strict
> mode typing, for exampl e ircmaxell his.
Benjamin,
As we discussed in personal exchanges, I really don't think I 'used' you and
it certai
67 matches
Mail list logo
