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 prior
On Fri, Feb 13, 2015 at 6:09 PM, Matteo Beccati p...@beccati.com wrote:
what does this have to do with using var?
Sorry. I posted to wrong thread.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
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
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
Le Thu Feb 05 2015 at 21:15:45, Andrea Faulds a...@ajf.me 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
Hi Lester,
On Fri, Feb 13, 2015 at 6:52 PM, Lester Caine les...@lsces.co.uk 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
Hi,
On Fri, Feb 13, 2015 at 2:33 AM, Netroby hufeng1...@gmail.com 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.
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:
Hi Levi,
On Sat, Feb 7, 2015 at 7:05 AM, Levi Morrison morrison.l...@gmail.com
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
On Thu, Feb 12, 2015 at 3:31 PM, Andrea Faulds a...@ajf.me wrote:
Hi Pavel,
On 12 Feb 2015, at 13:48, Pavel Kouřil pajou...@gmail.com 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
On Thu, Feb 12, 2015 at 6:01 PM, François Laupretre
franc...@tekwire.net 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).
Hi all,
On Fri, Feb 13, 2015 at 6:37 PM, Patrick ALLAERT patrickalla...@php.net
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
Hi all,
On Thu, Feb 12, 2015 at 8:57 PM, Andrea Faulds a...@ajf.me wrote:
On 12 Feb 2015, at 11:51, Pierre du Plessis pie...@pcservice.co.za
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.
Hey,
On 13 Feb 2015, at 07:28, Michael Wallner m...@php.net 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
On 13 בפבר׳ 2015, at 13:13, Andrea Faulds a...@ajf.me wrote:
Hi,
On 13 Feb 2015, at 09:37, Patrick ALLAERT patrickalla...@php.net 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
Nikita Popov wrote on 12/02/2015 23:33:
On Fri, Feb 13, 2015 at 12:06 AM, Ferenc Kovacs tyr...@gmail.com
mailto:tyr...@gmail.com 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
On 13 Feb 2015, at 11:16, Andrea Faulds a...@ajf.me wrote:
Hey,
On 13 Feb 2015, at 07:28, Michael Wallner m...@php.net 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
Hi,
On 13 February 2015 at 19:31, Andrea Faulds a...@ajf.me wrote:
On 13 Feb 2015, at 11:16, Andrea Faulds a...@ajf.me wrote:
Hey,
On 13 Feb 2015, at 07:28, Michael Wallner m...@php.net wrote:
On 12/02/15 19:55, Thomas Punt wrote:
I'd like to propose to make empty() a
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 isset’s.
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, though
De : Michael Wallner [mailto:mike.php@gmail.com] De la part de Michael
Wallner
I think the || behaviour is the most useful, as its the analogue of
issets. So !empty($a, $b, $c) would work similarly to isset($a, $b,
$c), and similarly, !isset($a, $b, $c) would work similarly to
Hi,
2015-02-13 14:45 GMT+01:00 Thomas Punt tp...@hotmail.co.uk:
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
Le Fri Feb 13 2015 at 12:34:29, Zeev Suraski z...@zend.com a écrit :
On 13 בפבר׳ 2015, at 13:13, Andrea Faulds a...@ajf.me wrote:
Hi,
On 13 Feb 2015, at 09:37, Patrick ALLAERT patrickalla...@php.net wrote:
Voted no because of the reasons already mentioned by a bunch of others
here.
Zeev,
On Fri, Feb 13, 2015 at 6:34 AM, Zeev Suraski z...@zend.com wrote:
On 13 בפבר׳ 2015, at 13:13, Andrea Faulds a...@ajf.me wrote:
Hi,
On 13 Feb 2015, at 09:37, Patrick ALLAERT patrickalla...@php.net wrote:
Voted no because of the reasons already mentioned by a bunch of others
here.
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 ;).
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
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 done to
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
On Wed, Feb 11, 2015 at 10:46 PM, Andrea Faulds a...@ajf.me wrote:
On 11 Feb 2015, at 21:30, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Wednesday, February 11, 2015 8:37 AM
To: Xinchen Hui; Andrea Faulds
Cc:
Hi,
On 13 Feb 2015, at 16:18, Benjamin Eberlei kont...@beberlei.de 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
On Wed, Feb 11, 2015 at 9:50 PM, Marcio Almada marcio.w...@gmail.com
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:
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.
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 formal
Thanks patch looks clean and It compiles , i will start testing it
On Fri, Feb 13, 2015 at 11:55 AM, Jan Ehrhardt php...@ehrhardt.nl 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!
Hey,
On 13 Feb 2015, at 16:24, Nikita Popov nikita@gmail.com 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
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 php...@ehrhardt.nl 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
Hi,
2015-02-13 18:37 GMT+01:00 Lester Caine les...@lsces.co.uk:
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
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 putting everything in the
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 have
On Sat, Feb 14, 2015 at 1:20 AM, Zeev Suraski z...@zend.com 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
On 13 Feb 2015, at 17:18, Lester Caine les...@lsces.co.uk 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
On 13 Feb 2015 19:37, Benjamin Eberlei kont...@beberlei.de 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
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 -
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 only
On Fri, Feb 13, 2015 at 5:59 PM, Andrea Faulds a...@ajf.me wrote:
Hi,
On 13 Feb 2015, at 16:18, Benjamin Eberlei kont...@beberlei.de wrote:
Wait i almost forgot, it *does* have an effect on me, especially around
callback handling:
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 tp...@hotmail.co.uk:
Hi Francois,
From: franc...@tekwire.net
May I suggest to extend your proposal to
On Fri, Feb 13, 2015 at 5:50 PM, Nikita Popov nikita@gmail.com wrote:
On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov nikita@gmail.com
wrote:
I'd like to follow up with another point. I've seen multiple people claim
that code that requires so many uses that this proposal becomes
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? All the use
Zeev,
On Fri, Feb 13, 2015 at 1:20 PM, Zeev Suraski z...@zend.com 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
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
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
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() only
On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com 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
On Sat, Feb 14, 2015 at 8:19 AM, Yasuo Ohgaki yohg...@ohgaki.net 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 {
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 to the
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
On 13 Feb 2015 22:31, Lester Caine les...@lsces.co.uk 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
-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 ask
why
2015-02-14 2:38 GMT+02:00 Leigh lei...@gmail.com:
On 14 February 2015 at 00:32, Benoit Schildknecht bensor...@neuf.fr 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
Hi Nikita,
On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov nikita@gmail.com 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
On Sat, Feb 14, 2015 at 1:09 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Nikita,
On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov nikita@gmail.com 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
On 14 February 2015 at 00:32, Benoit Schildknecht bensor...@neuf.fr 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
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
Could you revive it in a new thread please? :)
On Feb 13, 2015 3:25 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com
wrote:
Hi internals!
During the PHP 5.6 development cycle I have proposed an RFC [1] that
suggested the
Hi,
Le Sat, 14 Feb 2015 00:25:12 +0100, Nikita Popov nikita@gmail.com 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
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 (empty($a))
On 13/02/15 12:31, Andrea Faulds wrote:
On 13 Feb 2015, at 11:16, Andrea Faulds a...@ajf.me wrote:
Hey,
On 13 Feb 2015, at 07:28, Michael Wallner m...@php.net 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
Hi all,
On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre franc...@php.net
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
Hi Francois,
On Sat, Feb 14, 2015 at 12:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre franc...@php.net
wrote:
For method calls, overridden method should not evaluate parents
contract on entry.
It should be evaluated when parent method
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 void
Hey:
On Sat, Feb 14, 2015 at 11:18 AM, Andrea Faulds a...@ajf.me 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
HI,
On 14 February 2015 at 12:57, François Laupretre franc...@php.net 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
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
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.
It
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 I
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
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
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
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
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 a...@ajf.me 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
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
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 publish
82 matches
Mail list logo
