RE: [PHP-DEV] Design by Contract

I will try to explain but that’s not so clear for me too. The theory (from Eiffel guru) states that, to respect this fucking LSP rule, the pre-conditions to check when entering a method must be less strict than when entering its parent method. Don’t ask why, I don’t understand the reason ver

Re: [PHP-DEV] [RFC] Void Return Type

Hi! > I’ve written a small RFC and patch to add a “void” return type: > > https://wiki.php.net/rfc/void_return_type > > Please have a read over it. I think this would be a simple, yet useful > addition. I'm not sure what it is useful for, exactly. I mean, the more fatal errors the merrier, but

RE: [PHP-DEV] Design by Contract

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > >Open discussion is needed, of course. >What I meant is discussion for writing up draft RFC is close to finish. That's fine. > > For method calls, overridden method should not evaluate parents contract on > > entry.

RE: [PHP-DEV] Design by Contract

>De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > >Did you mean "Least Concern Principle" here? No : http://en.wikipedia.org/wiki/Liskov_substitution_principle. IMO, it is just a sort of best practice but OO people love it. François -- PHP Internals - PHP Runtime

Re: [PHP-DEV] [RFC] Void Return Type

Hey: On Sat, Feb 14, 2015 at 11:18 AM, Andrea Faulds wrote: > Hi everyone, > > I’ve written a small RFC and patch to add a “void” return type: > > https://wiki.php.net/rfc/void_return_type > > Please have a read over it. I think this would be a simple, yet useful > addition. be honest, I think

Re: [PHP-DEV] [RFC] Void Return Type

HI, On 14 February 2015 at 12:57, François Laupretre wrote: > > De : Andrea Faulds [mailto:a...@ajf.me] > > I've written a small RFC and patch to add a "void" return type: > > > > https://wiki.php.net/rfc/void_return_type > > > > Please have a read over it. I think this would be a simple, yet us

RE: [PHP-DEV] [RFC] Void Return Type

> De : Andrea Faulds [mailto:a...@ajf.me] > I’ve written a small RFC and patch to add a “void” return type: > > https://wiki.php.net/rfc/void_return_type > > Please have a read over it. I think this would be a simple, yet useful > addition. That's a nice addition and a beginning to distinguish

Re: [PHP-DEV] Design by Contract

Hi Francois, On Sat, Feb 14, 2015 at 12:53 PM, Yasuo Ohgaki wrote: > On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre > wrote: > >> > For method calls, overridden method should not evaluate parents >> contract on entry. >> > It should be evaluated when parent method is called. >> >> I alrea

Re: [PHP-DEV] Design by Contract

Hi Francois, On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre wrote: > > For method calls, overridden method should not evaluate parents contract > on entry. > > It should be evaluated when parent method is called. > > I already told you : the logic you are using for pre-conditions is NOT >

Re: [PHP-DEV] Design by Contract

Hi all, On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre wrote: > > > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > > > > We have discussed most of issues for https://wiki.php.net/rfc/dbc2 > > I am not sure anyone except hardly 5 people has the impression that

Re: [PHP-DEV] [RFC] Void Return Type

Do we really have to throw an catchable fatal error? the other return types make sense, why so strict? On 14 February 2015 at 11:18, Andrea Faulds wrote: > Hi everyone, > > I've written a small RFC and patch to add a "void" return type: > > https://wiki.php.net/rfc/void_return_type > > Please h

RE: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, > > I think this feature would be especially important if PHP gets function > autoloading (which it may yet gain in PHP 7 - a certain someone has been > working on it). If someone is working on function/constant autoloading, let me know, as I have a 100% BC RFC ready for this. I don't publis

[PHP-DEV] [RFC] Void Return Type

Hi everyone, I’ve written a small RFC and patch to add a “void” return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing

RE: [PHP-DEV] Design by Contract

Hi Yasuo, > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > > We have discussed most of issues for https://wiki.php.net/rfc/dbc2 I am not sure anyone except hardly 5 people has the impression that the subject was discussed, as the RFCs were not even officially anno

Re: [PHP-DEV] Allow dropping typehints during inheritance

If you consider the lack of an explicit type to mean the theoretical "Any" type which is a supertype of all types then dropping the hint is a form of contravariance. I would prefer to support normal contravariance for parameter types in which this is just a special case. However, I am not sure I wo

Re: [PHP-DEV] Allow dropping typehints during inheritance

Hi, I’m coming back to this thread after some discussions about related matters off-list. I’m firmly convinced this is a good idea, now: * It would be very useful to extend the callable type hint to support typed parameters and return types. If we were to do so, its validation rules should fo

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi, > On 14 Feb 2015, at 00:44, F & N Laupretre wrote: > > - The 'resource' hint does not exist 'as this would prevent moving from > resources to objects for existing extensions, which some have already done > (e.g. GMP)'. This is strange as moving an extension from resource to OO and > keepi

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

Could you revive it in a new thread please? :) On Feb 13, 2015 3:25 PM, "Nikita Popov" wrote: > On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov > wrote: > > > Hi internals! > > > > During the PHP 5.6 development cycle I have proposed an RFC [1] that > > suggested the use of exceptions instead of f

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

2015-02-14 2:38 GMT+02:00 Leigh : > On 14 February 2015 at 00:32, Benoit Schildknecht wrote: >> I don't think EngineException should inherit from Exception, it would be >> very dangerous. I'm sure a lot of exceptions are handled like this by a lot >> of devs, without creating custom exceptions : >

RE: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Andrea, After carefully reading the RFC again, and despite the fact that I globally agree, here are some suggestions and comments that were not discussed yet (sorry for this huge post) : - The 'resource' hint does not exist 'as this would prevent moving from resources to objects for existin

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

On 14 February 2015 at 00:32, Benoit Schildknecht wrote: > I don't think EngineException should inherit from Exception, it would be > very dangerous. I'm sure a lot of exceptions are handled like this by a lot > of devs, without creating custom exceptions : > Agreed, EngineException should be a b

[PHP-DEV] Re: [RFC] Exceptions in the engine

Hi, Le Sat, 14 Feb 2015 00:25:12 +0100, Nikita Popov a écrit: The question of whether EngineException should inherit from Exception is something we do have to consider now. Personally I prefer not introducing any special exception types that aren't caught by default. I think that would only

Re: [PHP-DEV] [RFC] Exceptions in the engine

On Sat, Feb 14, 2015 at 1:09 AM, Yasuo Ohgaki wrote: > Hi Nikita, > > On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov wrote: > >> As such I'm re-proposing this RFC for inclusion in PHP 7: >> >> https://wiki.php.net/rfc/engine_exceptions_for_php7 >> >> The RFC text is essentially the same as pre

Re: [PHP-DEV] [RFC] Exceptions in the engine

Hi Nikita, On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov wrote: > As such I'm re-proposing this RFC for inclusion in PHP 7: > > https://wiki.php.net/rfc/engine_exceptions_for_php7 > > The RFC text is essentially the same as previously, with the primary > difference being that parse errors are

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, Ralph The current namespace implementation is there to group code, which is > already does fairly successfully. > > I have to wonder if it is PHPStorm, IDE's and the like that have > "encouraged" people to only _use_ class names instead of a particular part > of a namespace (even if it is up t

Re: [PHP-DEV] Design by Contract

On Sat, Feb 14, 2015 at 8:19 AM, Yasuo Ohgaki wrote: > myMethod() { > require(MyMethod()); > } > My hand is not used to new syntax yet. This should be. myMethod() require(myMethid()) { /* */ } == Native DbC support syntax: class Child { require($this->age <

[PHP-DEV] Re: [RFC] Exceptions in the engine

On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov wrote: > Hi internals! > > During the PHP 5.6 development cycle I have proposed an RFC [1] that > suggested the use of exceptions instead of fatal errors in the engine. At > the time the proposal was declined, because the change was judged too > intru

Re: [PHP-DEV] Design by Contract

Hi all, We have discussed most of issues for https://wiki.php.net/rfc/dbc2 ==Missing parts of the RFC for me== - Advantage over annotation: Written as code, executed as code. ("Written as document, available as document" would be annotation advantage) - Advantage over assert() onl

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

You could very well argue that this is what relative syntax is for: use PhpParser\NodeVisitorAbstract; use PhpParser\Error; use PhpParser\Node; use PhpParser\Node\Stmt; use PhpParser\Node\Expr; then foo(Expr\New_ $expr) That is even more readable and cleaner to read. +1 The current namesp

RE: [PHP-DEV] [VOTE] Scalar Type Hints

> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 13, 2015 9:34 PM > To: Zeev Suraski > Cc: PHP Internals > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > Zeev, > > You said you disagreed with my post (meaning claims I made). I didn't as

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

On 13 Feb 2015 22:31, "Lester Caine" wrote: > Can't we restore the simple way of working in PHP7 > where it does not need to wrap around other things quite so closely? Hi Lester, This way if doing things on php didn't go anywhere, people just stopped using it because they saw better alternatives

[PHP-DEV][RFC][VOTE] Enable error_handler callback parameters to be passed by reference

Hi all! we'd like to initiate a vote on Allow error_handler callback parameters to be passed by reference: https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference We are proposing to enable error_handler callback parameters to be passed by reference to be able to append a

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hey Tom, "Thomas Punt" a écrit dans le message de groupe de discussion Hey Benoit, From: bensor...@neuf.fr Hi, I agree, this behaviour should be extended to all the is_* functions if possible. I'm not sure we can do that for all of the is_* functions, since is_callable() accepts up to

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hey Benoit, > From: bensor...@neuf.fr > Hi, > > I agree, this behaviour should be extended to all the is_* functions if > possible. > I'm not sure we can do that for all of the is_* functions, since is_callable() accepts up to three arguments rather than taking only a single argument like t

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Zeev, On Fri, Feb 13, 2015 at 1:20 PM, Zeev Suraski wrote: >> With that said, there's nothing stopping you from putting up your time to >> create a competing proposal and patch. If you really believe that weak >> types >> are the better way forward, why not codify that? If only one of the RFCs >>

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

On 13/02/15 17:46, Sebastian B.-Hagensen wrote: >>> I can’t say I miss the days of putting everything in the global namespace. >>> Makes it impossible to use two libraries with conflicting function names. >> > >> > Well one fix would be to have all the namespace stuff in the math.php >> > file? Al

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Sat, Feb 14, 2015 at 1:20 AM, Zeev Suraski wrote: >> With that said, there's nothing stopping you from putting up your time to >> create a competing proposal and patch. If you really believe that weak >> types >> are the better way forward, why not codify that? If only one of the RFCs >> passes

RE: [PHP-DEV] [VOTE] Scalar Type Hints

> With that said, there's nothing stopping you from putting up your time to > create a competing proposal and patch. If you really believe that weak > types > are the better way forward, why not codify that? If only one of the RFCs > passes, then you have your answer. If both pass, we can simply ha

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, Yasuo I think {} is better than []. > Using array operator for this seems a little strange to me. > I think this syntax is more like with block, not array. > > Regards, > Thanks for supporting the sintax choice, we tried a plethora of possibilities during research phase and "{" "}" seemed the

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

On Fri, Feb 13, 2015 at 5:50 PM, Nikita Popov wrote: > On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov > wrote: > > I'd like to follow up with another point. I've seen multiple people claim > that code that requires so many "use"s that this proposal becomes relevant > violates the single responsib

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

On Feb 13, 2015 8:41 AM, "Andrea Faulds" wrote: > > Hey, > > > On 13 Feb 2015, at 16:24, Nikita Popov wrote: > > > > I'm in favor of this RFC. Honestly I don't really understand the negativity > > it is getting around here. > > > > The ability to import multiple items from one namespace is a > >

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hi, ""Sebastian B.-Hagensen"" a écrit dans le message de groupe de discussion : caojcv8yx7vohtd1ja2obdrntdzb0q1soyqdyhsar3vt2vgs...@mail.gmail.com... 2015-02-13 14:45 GMT+01:00 Thomas Punt : Hi Francois, From: franc...@tekwire.net> May I suggest to extend your proposal to is_null() with t

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Fri, Feb 13, 2015 at 5:59 PM, Andrea Faulds wrote: > Hi, > > > On 13 Feb 2015, at 16:18, Benjamin Eberlei wrote: > > > > Wait i almost forgot, it *does* have an effect on me, especially around > callback handling: > > > > https://gist.github.com/schmittjoh/778e044deacc6f1fe516 > > > > Essenti

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, 2015-02-13 18:37 GMT+01:00 Lester Caine : > On 13/02/15 17:27, Andrea Faulds wrote: But with Marcio’s proposal, we could instead write this: >> >>use function SomeLibrary\Math\{sin, cos, tan, degrees, radius}; >>> > >>> > Well it used to be simply ... >>> > >>> > require Som

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

On 13/02/15 17:27, Andrea Faulds wrote: >>> But with Marcio’s proposal, we could instead write this: >>> >> >>> >>use function SomeLibrary\Math\{sin, cos, tan, degrees, radius}; >> > >> > Well it used to be simply ... >> > >> > require SomeLibrary\math.php; > I can’t say I miss the days of p

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

> On 13 Feb 2015, at 17:18, Lester Caine wrote: > > On 13/02/15 16:41, Andrea Faulds wrote: >> But with Marcio’s proposal, we could instead write this: >> >>use function SomeLibrary\Math\{sin, cos, tan, degrees, radius}; > > Well it used to be simply ... > > require SomeLibrary\math.php;

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

On 13/02/15 16:41, Andrea Faulds wrote: > But with Marcio’s proposal, we could instead write this: > > use function SomeLibrary\Math\{sin, cos, tan, degrees, radius}; Well it used to be simply ... require SomeLibrary\math.php; -- Lester Caine - G8HFL - Contact -

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On 13 Feb 2015 19:37, "Benjamin Eberlei" wrote: > > Wait i almost forgot, it *does* have an effect on me, especially around > callback handling: > > https://gist.github.com/schmittjoh/778e044deacc6f1fe516 > > Essentially callbacks are evaluated in the mode they are called in, not in > the one they

Re: [PHP-DEV] zend_get_parameters_ex rework

On 13/02/15 16:40, Jan Ehrhardt wrote: > It still gives some warnings at compile time. Most of them are caused by > > ib_link = (ibase_db_link *)zend_fetch_resource2_ex(IBG(default_link),\ > LE_LINK, le_link, le_plink); > > warning C4024: 'zend_fetch_resource2_ex' : different types for form

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On 13/02/2015 17:58, Matteo Beccati wrote: On 13/02/2015 17:29, Benjamin Eberlei wrote: Wait i almost forgot, it *does* have an effect on me, especially around callback handling: https://gist.github.com/schmittjoh/778e044deacc6f1fe516 Essentially callbacks are evaluated in the mode they are ca

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi, > On 13 Feb 2015, at 16:18, Benjamin Eberlei wrote: > > Wait i almost forgot, it *does* have an effect on me, especially around > callback handling: > > https://gist.github.com/schmittjoh/778e044deacc6f1fe516 > > Essentially callbacks are evaluated in the mode they are called in, not in

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On 13/02/2015 17:29, Benjamin Eberlei wrote: Wait i almost forgot, it *does* have an effect on me, especially around callback handling: https://gist.github.com/schmittjoh/778e044deacc6f1fe516 Essentially callbacks are evaluated in the mode they are called in, not in the one they are defined.

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov wrote: > On Wed, Feb 11, 2015 at 9:50 PM, Marcio Almada > wrote: > >> Hi internals! >> >> Since no new discussion topics appeared, the voting on the Group Use >> Declarations RFC for PHP7 is now open: >> >> RFC: https://wiki.php.net/rfc/group_use_dec

Re: [PHP-DEV] zend_get_parameters_ex rework

marius adrian popa in php.internals (Fri, 13 Feb 2015 17:56:28 +0200): >On Fri, Feb 13, 2015 at 11:55 AM, Jan Ehrhardt wrote: > >> https://github.com/Jan-E/php-src/commit/8c920a22ac65da485eaf3d2fd27baf2b0406116e >> >> Could you test that one? I did it as a sort of PHP7 exercise, but I do >> not ha

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hey, > On 13 Feb 2015, at 16:24, Nikita Popov wrote: > > I'm in favor of this RFC. Honestly I don't really understand the negativity > it is getting around here. > > The ability to import multiple items from one namespace is a > well-established feature you'll find in many languages employing s

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Wed, Feb 11, 2015 at 10:46 PM, Andrea Faulds wrote: > > > On 11 Feb 2015, at 21:30, Zeev Suraski wrote: > > > >> -Original Message- > >> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > >> Sent: Wednesday, February 11, 2015 8:37 AM > >> To: Xinchen Hui; Andrea Faulds > >> Cc: PHP In

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

On Wed, Feb 11, 2015 at 9:50 PM, Marcio Almada wrote: > Hi internals! > > Since no new discussion topics appeared, the voting on the Group Use > Declarations RFC for PHP7 is now open: > > RFC: https://wiki.php.net/rfc/group_use_declarations#votes > Patch: https://github.com/php/php-src/pull/1005

Re: [PHP-DEV] zend_get_parameters_ex rework

Thanks patch looks clean and It compiles , i will start testing it On Fri, Feb 13, 2015 at 11:55 AM, Jan Ehrhardt wrote: > Lester Caine in php.internals (Wed, 11 Feb 2015 12:43:05 +): > >OK I've got a patch for master, but I know that the changes are not > >complete! > > > >http://hg.lsces.o

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Zeev, On Fri, Feb 13, 2015 at 6:34 AM, Zeev Suraski wrote: > >> On 13 בפבר׳ 2015, at 13:13, Andrea Faulds wrote: >> >> Hi, >> >>> On 13 Feb 2015, at 09:37, Patrick ALLAERT wrote: >>> >>> Voted "no" because of the reasons already mentioned by a bunch of others >>> here. >>> >>> Weak type hint a

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Le Fri Feb 13 2015 at 12:34:29, Zeev Suraski a écrit : > > On 13 בפבר׳ 2015, at 13:13, Andrea Faulds wrote: > > Hi, > > On 13 Feb 2015, at 09:37, Patrick ALLAERT wrote: > > > Voted "no" because of the reasons already mentioned by a bunch of others > here. > > > Weak type hint as presented earli

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hi, > Date: Fri, 13 Feb 2015 15:09:16 +0100 > From: sbj.ml.r...@gmail.com > > While I don't know how common such a usage is I'm certain that there > is a use case for it. However, just modifying a subset of the is_* > functions sounds like a bad idea. If such a change is applied it > should be do

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hi, 2015-02-13 14:45 GMT+01:00 Thomas Punt : > Hi Francois, > >> From: franc...@tekwire.net> >> May I suggest to extend your proposal to is_null() with the same logic ? > If we were to do the same with is_null(), then would it not be best to do it > with all the is_*() functions? I would be more

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hi Francois, > From: franc...@tekwire.net> > May I suggest to extend your proposal to is_null() with the same logic ? If we were to do the same with is_null(), then would it not be best to do it with all the is_*() functions? I would be more than happy to cater for those functions as well, thoug

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

> De : Michael Wallner [mailto:mike.php@gmail.com] De la part de Michael Wallner > > > I think the || behaviour is the most useful, as it’s the analogue of > > isset’s. So !empty($a, $b, $c) would work similarly to isset($a, $b, > > $c), and similarly, !isset($a, $b, $c) would work similarly to

RE: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

Hi, > De : Pierre Joye [mailto:pierre@gmail.com] > > So we do not want to kill them because they are still used (but dead). > But we may come with some wrapper to replace almost all the features > provided by the dead libs? At least for mcrypt, good luck to anyone > willing to do that for imap

RE: [PHP-DEV] [VOTE] Scalar Type Hints

> De : Dennis Birkholz [mailto:den...@birkholz.biz] > > 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 further look: > > 1. There is no float (without !) in the list. It should be IS_LONG = yes > (if value does not exceed float

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

On 13/02/15 12:31, Andrea Faulds wrote: > >> On 13 Feb 2015, at 11:16, Andrea Faulds wrote: >> >> Hey, >> >>> On 13 Feb 2015, at 07:28, Michael Wallner wrote: >>> >>> On 12/02/15 19:55, Thomas Punt wrote: >>> I'd like to propose to make empty() a variadic, where if any arguments p

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hi Reeze, > From: re...@php.net > > For example: echo $a, $b, $c, & empty($a, $b, $c), they are treated equal, > > if the empty() means if any one of them is empty then result is TRUE, the > advantage of it disappeared: > > if (empty($a, $b, $c)) { > // you might want to check it again. > if (e

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hi, > From: a...@ajf.me> > * I assume Thomas actually meant “where if any arguments passed in are > considered empty, then *true* is returned”, i.e. (empty($a) || empty($b) || > empty($c)) > > Sorry for the confusion. > > I think the || behaviour is the most useful, as it’s the analogue of iss

Re: [PHP-DEV] Remove $this from incompatible context

Kris Craig wrote on 12/02/2015 21:45: Since it's very common for environments to display E_WARNING but not E_NOTICE, some devs-- particularly those who are less experienced in PHP-- can end up wasting a lot of time trying to chase down the behavior because they're not seeing any errors. If pe

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hi, On 13 February 2015 at 19:31, Andrea Faulds wrote: > > > On 13 Feb 2015, at 11:16, Andrea Faulds wrote: > > > > Hey, > > > >> On 13 Feb 2015, at 07:28, Michael Wallner wrote: > >> > >> On 12/02/15 19:55, Thomas Punt wrote: > >> > >>> I'd like to propose to make empty() a variadic, where if

Re: [PHP-DEV] [VOTE] Scalar Type Hints

> On 13 בפבר׳ 2015, at 13:13, Andrea Faulds wrote: > > Hi, > >> On 13 Feb 2015, at 09:37, Patrick ALLAERT wrote: >> >> Voted "no" because of the reasons already mentioned by a bunch of others >> here. >> >> Weak type hint as presented earlier: +1 (and very good job Andrea about >> that!).

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

> On 13 Feb 2015, at 11:16, Andrea Faulds wrote: > > Hey, > >> On 13 Feb 2015, at 07:28, Michael Wallner wrote: >> >> 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

Re: [PHP-DEV] Remove $this from incompatible context

Nikita Popov wrote on 12/02/2015 23:33: 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 w

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

Hey, > On 13 Feb 2015, at 07:28, Michael Wallner wrote: > > 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 considere

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi, > On 13 Feb 2015, at 09:37, Patrick ALLAERT wrote: > > Voted "no" because of the reasons already mentioned by a bunch of others here. > > Weak type hint as presented earlier: +1 (and very good job Andrea about > that!). > declare(strict_types=1): -1, not only about the syntax, but also abo

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi all, On Fri, Feb 13, 2015 at 6:37 PM, Patrick ALLAERT wrote: > Voted "no" because of the reasons already mentioned by a bunch of others > here. > > Weak type hint as presented earlier: +1 (and very good job Andrea about > that!). > declare(strict_types=1): -1, not only about the syntax, but a

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 12, 2015 at 6:01 PM, François Laupretre wrote: > Hi Robert, > >> De : Robert Stoll [mailto:p...@tutteli.ch] >> >> There are several programming languages which do support dynamic typing >> and method overloading somehow (Clojure, Erlang, Prolog, Cecil and >> certainly more). Most of t

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 12, 2015 at 3:31 PM, Andrea Faulds wrote: > 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

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors Update

Hi Levi, On Sat, Feb 7, 2015 at 7:05 AM, Levi Morrison wrote: > I have updated the RFC for removing PHP 4 constructors[1]. Notably, I > have pushed off the removal to PHP 8, and instead only deprecate them > in PHP 7. The rationale is that eventual consistency in this matter is > good enough for

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi, On Fri, Feb 13, 2015 at 2:33 AM, Netroby wrote: > 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. > If you look

Re: [PHP-DEV] Legal date generated from illegal date

Hi Lester, On Fri, Feb 13, 2015 at 6:52 PM, Lester Caine wrote: > Management of dates is controversial in a lot more areas than just using > the wrong calendar in prior times ;) > Each database uses it's own way to handle dates and time internally, and > most default actions are different, add t

Re: [PHP-DEV] zend_get_parameters_ex rework

Lester Caine in php.internals (Wed, 11 Feb 2015 12:43:05 +): >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 This one might be a little bit more complete: https://github.com/Jan-E/php-src/commit/8c920a22ac65d

Re: [PHP-DEV] Legal date generated from illegal date

On 13/02/15 04:03, Yasuo Ohgaki wrote: > I see controversial behavior here, unserialize raises error while new > DateTime('-00-00') doesn't. > > If it's a bug, I'll just file it as a bug. Yasuo Management of dates is controversial in a lot more areas than just using the wrong calendar in prio

Re: [PHP-DEV] Remove $this from incompatible context

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?

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Le Thu Feb 05 2015 at 21:15:45, Andrea Faulds a écrit : Good evening, > > At long last, I’m going to put the RFC to a vote. It’s been long enough - > I don’t think there needs to be, or will be, much further discussion. > > I’d like to make sure that everyone voting understands the RFC fully. > P

Re: [PHP-DEV] [RFC] Deprecate properties using var

On Fri, Feb 13, 2015 at 6:09 PM, Matteo Beccati wrote: > what does this have to do with using "var"? Sorry. I posted to wrong thread. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] [RFC] Deprecate properties using var

On 13/02/2015 09:27, Yasuo Ohgaki wrote: I thought I filed this as Trait bug, but there isn't. I might forgot to report it. http://3v4l.org/pL3Hr Class calls trait function that is PHP4 constructor. This could be resolved by removing PHP4 constructor. what does this have to do with using "var

Re: [PHP-DEV] [RFC] Deprecate properties using var

Hi all, On Thu, Feb 12, 2015 at 8:57 PM, Andrea Faulds wrote: > > 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 prev