On 1/20/2013 3:11 PM, Gordon Oheim wrote:
Am 17.01.2013 19:20, schrieb Clint Priest:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
this happen for 5.5, voting and the specificat
On 1/21/2013 12:36 PM, Richard Quadling wrote:
Hello.
This may have already been covered, so apologies ...
With https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#references,
the return by reference is handled by the use of &get{}.
How about pass-by-reference for set{}?
It works, it was simpl
Am 21.01.2013 23:59, schrieb Nikita Popov:
> Sorry if it wasn't clear: The nullability stuff only applies if a
typehint
> is used. If no typehint is used, then you can freely assign null,
regardless
> of whether or not you have the "= null" in the declaration
> (no typehint = everything's valid
On Mon, Jan 21, 2013 at 11:54 PM, Crypto Compress <
cryptocompr...@googlemail.com> wrote:
> Hello Nikita,
>
> for me this "maybe-of-type"-typehinting is a small progression in the right
> direction.
>
> But "Default values and nullability" would break existing code as you need
> to add a default n
Hello Nikita,
for me this "maybe-of-type"-typehinting is a small progression in the right
direction.
But "Default values and nullability" would break existing code as you need
to add a default null at "design-time" (BC break):
a = $a;
$this->b = $b;
}
}
// test only a
$c = new C("f
On 01/14/2013 01:18 AM, Pierre Joye wrote:
Arg, sorry :)
Here you go:
https://wiki.php.net/rfc/php53eol
Pierre,
Can you review this RFC and the votes? The wording "5.5 final
release" needs assessing. You probably meant "first 5.5 production
release". If anyone interpreted it as it is ac
On Mon, 21 Jan 2013 20:28:12 +0100, Anthony Ferrara
wrote:
Gustavo
I've voted "No" due to concerns I mentioned in most part in IRC, but
which
I think should be here on the record. So my voting statement:
I'm voting against this proposal because I think the proposed syntax
strongly sugges
Gustavo
I've voted "No" due to concerns I mentioned in most part in IRC, but which
> I think should be here on the record. So my voting statement:
>
> I'm voting against this proposal because I think the proposed syntax
> strongly suggests that the property is bound to a specific type. This has
>
Gustavo Lopes wrote:
* And yes, next we'll start discussing extending this to other variables. Yes,
this is a slippery slope argument. Slippery slopes are a real phenomenon. People
interested in this topic can read this reference [1].
I'm with you on that Gustavo - but I can't vote. I'm against A
On Mon, 21 Jan 2013 19:03:09 +0100, Nikita Popov
wrote:
I've opened the vote on the proposal for the alternative accessor
typehinting syntax:
https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax#voting
The vote is done under the assumption that the main accessors RFC
Hello.
This may have already been covered, so apologies ...
With https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#references,
the return by reference is handled by the use of &get{}.
How about pass-by-reference for set{}?
Normally, a function definition dictates this.
But if $value is alread
Hi internals!
I've opened the vote on the proposal for the alternative accessor
typehinting syntax:
https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax#voting
The vote is done under the assumption that the main accessors RFC will
pass. If it does not, then this proposal
Le 21/01/2013 10:10, Nikita Popov a écrit :
> On Mon, Jan 21, 2013 at 9:17 AM, "SPONEM, Benoît"
> mailto:b.spo...@baclesse.fr>> wrote:
>
> Hi
>
> This typehinting will support the basic types (int, string) ?
>
> Benoit
>
>
> It will support them only when scalar typehints are added for
13 matches
Mail list logo
