Am 11.03.2015 um 17:21 schrieb Rowan Collins:
My reasoning is that code that is ambiguous is hard to read. If $foo
can mean either a local variable called $foo or a property of the
current object called $foo, then you have to know which it is in order
to understand what code is doing.
So
2015-03-10 12:31 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:
Hello,
Le lun. 2 mars 2015 à 00:03, Marcio Almada marcio.w...@gmail.com a
écrit :
I'm globally +0.5, however I have some concerns:
What about constructors?
Children classes may have a bigger number of arguments for
On 12 Mar 2015, at 02:21, Johannes Ott m...@deroetzi.de wrote:
So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here first.
The purpose of this suggestion is to introduce a static constructor,
which is called before
Am 11.03.2015 um 14:03 schrieb Rowan Collins:
Johannes Ott wrote on 10/03/2015 20:46:
okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must say again that PHP needs a less dynamic
On Thursday 12 March 2015 00:10:15 Rowan Collins wrote:
On 11/03/2015 23:21, Johannes Ott wrote:
The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to initialize some static properties which are
-Original Message-
From: Ole Markus With [mailto:olemar...@olemarkus.org]
Sent: Thursday, March 12, 2015 10:10 AM
To: Pierre Joye; Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On 03/11/2015 09:05 PM, Pierre Joye wrote:
On Mar 12,
You have to input internals@lists.php.net, that changed some time ago.
I've just updated https://wiki.php.net/rfc/howto
See
https://github.com/php/web-wiki/commit/583d2c1b39a8b88960ab94e56ba4a4608ddb2353
Regards, Niklas
2015-03-11 14:43 GMT+01:00 Johannes Ott m...@deroetzi.de:
Am 11.03.2015 um
On 03/11/2015 09:05 PM, Pierre Joye wrote:
On Mar 12, 2015 2:10 AM, Zeev Suraski z...@zend.com wrote:
The vote on the Coercive Scalar Type Hints is now open for voting.
The latest version of the RFC includes changes discussed on internals@
last
week:
1. Accept string-bool and
On Thursday 12 March 2015 00:21:34 Johannes Ott wrote:
The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to initialize some static properties which are needed by the
class.
We are doing this in our
Le mar. 10 mars 2015 à 21:04, Marcio Almada marcio.w...@gmail.com a
écrit :
2015-03-10 12:31 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:
Hello,
Le lun. 2 mars 2015 à 00:03, Marcio Almada marcio.w...@gmail.com a
écrit :
I'm globally +0.5, however I have some concerns:
What
In addition, I'm voting no for the following reasons (in addition to
Dan's):
1. It downplays the BC breaks. It says:
Given the change to the acceptable values into a wide range of
internal
functions, this RFC is likely to result in a substantial number of newly
introduced
On 12/03/15 08:29, Zeev Suraski wrote:
There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago.
Zeev ... being realistic I think that the chances of getting
What about inheritance?
I think dynamic class-constructor would make much more sense.
A function which can analyse real class and do initialisation.
class A
{
protected static function __class_construct()
{
echo get_called_class().” class is defined\n;
}
}
Am 12.03.2015 um 05:17 schrieb Levi Morrison:
On Wed, Mar 11, 2015 at 6:10 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 11/03/2015 23:21, Johannes Ott wrote:
So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here
On 11.03.15 22:28, Bob Weinand wrote:
after all, some people are not happy with the current proposals about scalar
types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
https://wiki.php.net/rfc/basic_scalar_types
2015-03-12 11:23 GMT+02:00 Zeev Suraski z...@zend.com:
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Thursday, March 12, 2015 12:46 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
Correct. It's just for the
2015-03-12 4:08 GMT+02:00 Lester Caine les...@lsces.co.uk:
On 11/03/15 22:44, Yasuo Ohgaki wrote:
Having namespace for internals would bring much flexibility for API
changes, both
OO and procedural API. I may try my best to have consensus.
I think you also like to have OO style API for
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Thursday, March 12, 2015 12:46 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
Correct. It's just for the case where the other two fail.
We still can add strict mode in a
So really, the options we have are:
1. Put this one for a vote before the end of tomorrow. Here too, on a
personal level, if I see that this proposal isn't gaining enough votes,
I'd
support the dual mode one.
2. Don't put it up for a vote, and then we may or may not have
something
for
On 12/03/15 09:21, Arvids Godjuks wrote:
Basically this.
Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one
now, and adding a new subset of it looks pointless. It has it's problems
and legacy, you
Hey PHP Internals,
So there hasn't been much discussion on this RFC, and yet a lot of people have
voted -1 on it. This is a little disappointing because I'm not entirely sure why
people are against it - and no one seems to want to debate it either.
From pre-RFC discussions, two main concerns
Do you mean the PostgreSQL driver needs to be changed from pg_blah() to
pgBlah() ?
It was that extra underscores having been added to the pg_ functions is
being put forward as a reason for adding them everywhere else. That is
perhaps when this discussion should have been undertaken, but
Hello Johannes,
class Foo {
private static function __static() {
throw new Exception(boom);
}
}
while(true) {
try {
$foo = new Foo;
} catch (Exception ex) {}
}
Would this code be valid?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
2015-03-12 11:41 GMT+02:00 Lester Caine les...@lsces.co.uk:
On 12/03/15 09:21, Arvids Godjuks wrote:
Basically this.
Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one
now, and adding a new
Am 12.03.2015 um 12:33 schrieb Johannes Ott:
Am 12.03.2015 um 12:16 schrieb Crypto Compress:
Hello Johannes,
class Foo {
private static function __static() {
throw new Exception(boom);
}
}
while(true) {
try {
$foo = new Foo;
} catch (Exception ex) {}
}
Johannes Ott wrote on 12/03/2015 08:54:
Am 12.03.2015 um 05:17 schrieb Levi Morrison:
On Wed, Mar 11, 2015 at 6:10 PM, Rowan Collins rowan.coll...@gmail.com wrote:
On 11/03/2015 23:21, Johannes Ott wrote:
So now I want to do my first own proposal for a new function in PHP and
I hope doing it
On 11 March 2015 at 21:44, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Improvement ideas are welcome...
Hi Dmitry,
The idea was raised before of having both soft and hard limits for the
memory consumption and time limits, and to trigger a user defined
callback when the soft limit was reached.
On 12/03/15 14:28, Umberto Salsi wrote:
Hi all,
I'm not a PHP internals developer, but this might be a bug spread here and
there in the source. This coding pattern:
if(php_stream_read(..., n) != n){
php_error_docref(NULL TSRMLS_CC, E_SOMETHING, Read error!);
seems wrong to me because
Hi all,
I'm not a PHP internals developer, but this might be a bug spread here and
there in the source. This coding pattern:
if(php_stream_read(..., n) != n){
php_error_docref(NULL TSRMLS_CC, E_SOMETHING, Read error!);
seems wrong to me because there might be streams that returns less than
n
Most of these examples are just crying out to be real objects, not
static classes. You might not want to be creating them every time you
use them, but that's what patterns like Singletons and Dependency
Injection are for.
I really disagree to this. Singletons are a typical
Hey:
We have CALL SWITCH GOTO vm kind supports for long time.
And we use CALL for default.
SWITCH GOTO seems useless now, and brings us some troubles while
maintaining .
And also could make some extension unable to work, like in phpdbg:
PHPDBG_G(vmret) =
On Mar 11, 2015, at 2:28 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi all,
after all, some people are not happy with the current proposals about scalar
types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
Johannes Ott wrote on 12/03/2015 14:51:
That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem). That should be encapsulated inside a proper
method body.
I agree, but as such, I think
Am 12.03.2015 um 12:40 schrieb Niklas Keller:
How would it behave for the second call? If the first initialize fails due
to some exception, should that static constructor be executed again?
I think there a two different solutions and I do not know which one I
prefer at the moment:
1. No
On Thu, 12 Mar 2015, Thomas Punt wrote:
Hey PHP Internals,
So there hasn't been much discussion on this RFC, and yet a lot of people have
voted -1 on it. This is a little disappointing because I'm not entirely sure
why
people are against it - and no one seems to want to debate it either.
Am 12.03.2015 17:28 schrieb Larry Garfield la...@garfieldtech.com:
I thought it sounded familiar. Also check the list archive for A modest
proposal: __constructStatic from a month ago. It was rejected then, too.
That proposal was about a completely different issue.
But you are right, it was
On 3/12/15 4:11 AM, Lester Caine wrote:
On 12/03/15 08:29, Zeev Suraski wrote:
There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago.
Zeev ... being realistic
Am 12.03.2015 um 16:57 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 14:51:
That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem). That should be encapsulated inside a
On 12 Mar 2015, at 19:28, Larry Garfield la...@garfieldtech.com wrote:
I thought it sounded familiar. Also check the list archive for A modest
proposal: __constructStatic from a month ago. It was rejected then, too.
Really, I cannot think of any cases where I want to have a static
On 12/03/15 16:55, Larry Garfield wrote:
On 3/12/15 4:11 AM, Lester Caine wrote:
On 12/03/15 08:29, Zeev Suraski wrote:
There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more
Johannes Ott wrote on 12/03/2015 17:05:
Am 12.03.2015 um 16:57 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 14:51:
That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem).
Johannes Ott wrote on 12/03/2015 19:45:
All of the magic methods are doing like this.
I thought you might say that, but the only thing remotely similar I can
think of is a destructor, which gets called when an object goes out of
scope; the others are all the implementation of, or instead
On 3/12/15 10:57 AM, Rowan Collins wrote:
Johannes Ott wrote on 12/03/2015 14:51:
That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem). That should be encapsulated inside a proper
Hey Dan,
The falsy semantics of empty() means that inlining its behaviour to exactly
match
isset() isn't logical.
The problem isn't so much that the behaviour doesn't match some other
pattern in PHP; the problem is that the function doesn't do what its
name says it does.
if any
Am 12.03.2015 um 18:55 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 17:05:
Am 12.03.2015 um 16:57 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 14:51:
That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For
Hey Derick,
IMO, because it's not obvious whether it is *all* empty, or *atleast
one* empty. The same argument we had before, when we expanded isset() to
be variadic. We had the same discussion then, resulting on keeping
empty() as it is.
One discussion 11 years ago:
Patrick Schaaf wrote on 12/03/2015 18:40:
Am 12.03.2015 18:56 schrieb Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com:
Johannes Ott wrote on 12/03/2015 17:05:
So doing a null check each time
is a overhead of calculation which can be avoided with this static
Am 12.03.2015 um 20:34 schrieb Rowan Collins:
Patrick Schaaf wrote on 12/03/2015 18:40:
Am 12.03.2015 18:56 schrieb Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com:
Johannes Ott wrote on 12/03/2015 17:05:
So doing a null check each time
is a overhead of
Am 12.03.2015 18:56 schrieb Rowan Collins rowan.coll...@gmail.com:
Johannes Ott wrote on 12/03/2015 17:05:
So doing a null check each time
is a overhead of calculation which can be avoided with this static
constructor pattern.
Presumably the engine would need to perform some implicit
Am 12.03.2015 20:12 schrieb Dan Ackroyd dan...@basereality.com:
Patrick Schaaf wrote:
But that has proven, in the past, a fountain of joy wrt.
placement, with variations needed for APC and opcache, and general
frustration
all around.
Is there a bug report for the problems? OPCache
Patrick Schaaf wrote:
But that has proven, in the past, a fountain of joy wrt.
placement, with variations needed for APC and opcache, and general frustration
all around.
Is there a bug report for the problems? OPCache shouldn't have
side-effects on the code.
cheers
Dan
On 12 March 2015 at
Am 12.03.2015 um 21:33 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 19:45:
All of the magic methods are doing like this.
I thought you might say that, but the only thing remotely similar I can
think of is a destructor, which gets called when an object goes out of
scope; the
Johannes Ott wrote:
And i although see no DI or Singleton pattern to use here to get the
same functionality, if you want to use like Config::getHostname() and
not like Config::getInstance()-getHostname() which is really
unnecessary abstraction level for nothing in my opinion!
It is possible,
Le 26/02/2015 15:58, Anthony Ferrara a écrit :
I have opened voting on Scalar Type Declarations v0.5. Please cast your vote.
Hi,
We were, at AFUP, +1 for the v0.3 of this RFC, and it seems we still are
on the +1 side for this v0.5
Thanks for having re-vived this!
--
Pascal MARTIN, AFUP -
On 12 March 2015 at 09:58, Thomas Punt tp...@hotmail.co.uk wrote:
Hey PHP Internals,
I'm not entirely sure why
people are against it - and no one seems to want to debate it either.
I think these were covered in the discussion phase, but I will
reiterate the reasons I voted against it for
Patrick Schaaf wrote on 12/03/2015 08:40:
On Thursday 12 March 2015 00:10:15 Rowan Collins wrote:
On 11/03/2015 23:21, Johannes Ott wrote:
The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to
Am 12.03.2015 um 12:16 schrieb Crypto Compress:
Hello Johannes,
class Foo {
private static function __static() {
throw new Exception(boom);
}
}
while(true) {
try {
$foo = new Foo;
} catch (Exception ex) {}
}
Would this code be valid?
Have to think
2015-03-12 12:33 GMT+01:00 Johannes Ott m...@deroetzi.de:
Am 12.03.2015 um 12:16 schrieb Crypto Compress:
Hello Johannes,
class Foo {
private static function __static() {
throw new Exception(boom);
}
}
while(true) {
try {
$foo = new Foo;
}
On 10 March 2015 at 15:02, Anthony Ferrara ircmax...@gmail.com wrote:
Can we please come down to a single RFC, with a single vote yes/no?
It's easier to understand, easier to manage and has less possibility
of gaming.
While I generally agree, in the case where there is a small detail
that
On Tue, 10 Mar 2015, Patrick ALLAERT wrote:
2015-03-10 16:02 GMT+01:00 Anthony Ferrara ircmax...@gmail.com:
Can we please come down to a single RFC, with a single vote yes/no?
It's easier to understand, easier to manage and has less possibility
of gaming.
That is much more stricter
Welcome!!!
I'd love to hear more about your thesis if you can share!
Anthony
On Tue, Mar 10, 2015 at 6:56 AM, Johannes Ott m...@deroetzi.de wrote:
Hi,
sorry I did the wrong order, starting to discuss already without
introducing me first:
My name is Johannes Ott. I am 31 years old. I'm
Voting no due to:
i) Having conversion rules be difference in userland to internal functions.
You list 'Single Mode' as a benefit of this RFC, but it's only single
mode if you gloss over this difference. This is a massive cognitive
load, and will be one of those issues that catches users out
62 matches
Mail list logo
