On Mon, Jan 21, 2013 at 7:54 PM, Gustavo Lopes wrote:
> * It's a promise that's not guaranteed. As long as the getter is allowed
> to reference the value of the variable can arbitrarily be changed to
> whatever type. It may also be possible to do the same with unserialization.
>
Yes, that's a goo
Am 22.01.2013 09:07, schrieb Nikita Popov:
It's not just about the lines of code. It's about having a more readable
and more intuitive syntax. Am I the only one who thinks that "public $date
{ get; set(DateTime $date); }" looks pretty ugly/unclear compared to
"public DateTime $date;"?
FWIW: I a
On 2013-01-18, Stanislav Malyshev wrote:
> Commit:33b104c778c5c0e5446671397aaddd66efa4a7bc
> Author:Stanislav Malyshev Mon, 14 Jan 2013
> 00:06:09 -0800
> Parents: f63a9f6c11c05aa76158b6cae0e05340d303a6af
> Branches: PHP-5.3 PHP-5.4 PHP-5.5 master
>
> Link:
> http://git
On 2013-01-19, Xinchen Hui wrote:
> Commit:f7b99c481d0a943d922e99ad9afa82c45193030e
> Author:Xinchen Hui Sat, 19 Jan 2013 17:01:57
> +0800
> Parents: e23fca8910b96f1c3bb26c6582c17c92fd6f2f7a
> Branches: PHP-5.5
>
> Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;
Hi!
> this appears to break tests/classes/unset_properties.phpt on 5.5 branch,
> can you please look into this?
>
Thanks, fixed.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
On Tue, Jan 22, 2013 at 4:21 PM, David Soria Parra wrote:
> On 2013-01-19, Xinchen Hui wrote:
>> Commit:f7b99c481d0a943d922e99ad9afa82c45193030e
>> Author:Xinchen Hui Sat, 19 Jan 2013 17:01:57
>> +0800
>> Parents: e23fca8910b96f1c3bb26c6582c17c92fd6f2f7a
>> Branches: PHP-5.5
On Tue, 22 Jan 2013 09:38:11 +0100, Stas Malyshev
wrote:
this appears to break tests/classes/unset_properties.phpt on 5.5 branch,
can you please look into this?
Thanks, fixed.
Seems to be failing on 5.4 as well.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
On 22 January 2013 01:08, Clint Priest wrote:
> 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{}.
>
>
On 1/17/2013 12:20 PM, Clint Priest wrote:
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 specifications are here:
https://wiki.php.net/rfc
Clint Priest wrote:
There seems to be a lot of userland support for this proposal from people who
don't have voting rights.
And what about the userland people who don't want the additional complexity who
don't have voting rights?
--
Lester Caine - G8HFL
-
Contact
@Lester seems pretty much opt-in to me :)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
2013/1/22 Lester Caine
> Clint Priest wrote:
>
>> There seems to be a lot of userland support for this proposal from people
>> who
>> don't have voting rights.
>>
>
> And what about the userland people who don't want the additional
> complexity who don't have voting rights?
Don't use it. Regard
On 22 January 2013 08:15, Lars Schultz wrote:
> Am 22.01.2013 09:07, schrieb Nikita Popov:
>
>> It's not just about the lines of code. It's about having a more readable
>> and more intuitive syntax. Am I the only one who thinks that "public $date
>> { get; set(DateTime $date); }" looks pretty ugly
Has there ever been any discussion on an __init magic method for
bootstraping static properties on class load?
The usual solution I come up with is manually calling an init method post
class definition, which works, though I'd call it slighly less than elegant:
class Foo {
static $bar;
st
@Pete actually, your "less than elegant" solution seems quite enough for
this use case.
What's your use case for this kind of static properties? What if you make
them private/protected and use an accessor method to initialize them (and
avoid the overhead during autoloading)?
Marco Pivetta
http:/
>
> What's your use case for this kind of static properties? What if you make
> them private/protected and use an accessor method to initialize them (and
> avoid the overhead during autoloading)?
>
It's the overhead of repeatedly calling an accessor method which I'd prefer
to avoid.
--
Pete Boe
Sebastian Krebs wrote:
Clint Priest wrote:
There seems to be a lot of userland support for this proposal from
people who
don't have voting rights.
And what about the userland people who don't want the additional complexity
who don't have voting rights?
Don't
@Lester your explanation simply exposes the fact that your resources to
upgrade to newer technologies are insufficient. This doesn't mean that
newer technologies don't have to exist.
And no, it won't be possible to fix all bugs/flaws before getting a new
feature. We'd all be running in circles loo
Hi,
On Tue, 2013-01-22 at 12:29 +, Pete Boere wrote:
> Has there ever been any discussion on an __init magic method for
> bootstraping static properties on class load?
Adding an __init method as you wish will just add complexity and gain
very little. What complexity am I talking about? Well l
On 1/22/2013 6:55 AM, Marco Pivetta wrote:
@Lester your explanation simply exposes the fact that your resources to
upgrade to newer technologies are insufficient. This doesn't mean that
newer technologies don't have to exist.
And no, it won't be possible to fix all bugs/flaws before getting a n
Clint Priest wrote:
And no, it won't be possible to fix all bugs/flaws before getting a new
feature. We'd all be running in circles looking for perfection :)
I can agree that some things need fixing though, perhaps Lester could put
together an RFC detailing the myriad of things he deems critical
> For those that have voted against this proposal, are there any
> clarifications that can be made or questions answered?
I can say that this bit is particularly confusing:
public $foo {}
My understanding that this code will not emit any warnings when
interpreted, but the $foo property has n
I am actually going to +1 this idea I thought about discussing it, but opted
out of it because classes are most often in their own file and if you need to
do some static binding you can do it at the end of the file after the class
definition. However, I do believe this idea would make it easier
@Pete just FYI, PSR-1 excludes that such a logic should exist in a loaded
file:
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md#23-side-effects
Not sure if you are interested in following the FIG on these ideas, but the
guideline makes actually sense.
Am 22.01.2013 02:46, schrieb Clint Priest:
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
th
I've wanted a binary PKBDF2() function into PHP for a very long time and
didn't want to wait for 5.5 release.
Get the patch from:
http://blog.hqcodeshop.fi/archives/11-Back-ported-hash_pbkdf2-from-PHP-5.5.html
Hope this helps somebody.
Regards,
Jari Turkia
--
PHP Internals - PHP Runtime Dev
On 01/22/2013 03:18 AM, Clint Priest wrote:
>
> On 1/17/2013 12:20 PM, Clint Priest wrote:
>> 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 a
https://wiki.php.net/rfc/sendrecvmsg
The module ext/sockets, a wrapper around the sockets API, does not include
support to recvmsg() and sendmsg(). This RFC addresses this shortcoming by
support introducing limited (only a few types of messages are supported)
support for these functions.
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf wrote:
> The simple explanation from me is that the ROI isn't there on this one.
> It adds a lot of code complexity for very little return. Yes, it saves a
> couple of lines of boilerplate code for a few people, but the cost is
> high in terms of on
On 1/22/2013 11:20 AM, Rasmus Lerdorf wrote:
On 01/22/2013 03:18 AM, Clint Priest wrote:
For those that have voted against this proposal, are there any
clarifications that can be made or questions answered?
There seems to be a lot of userland support for this proposal from
people who don't hav
On 1/22/2013 9:24 AM, Levi Morrison wrote:
For those that have voted against this proposal, are there any
clarifications that can be made or questions answered?
I can say that this bit is particularly confusing:
public $foo {}
My understanding that this code will not emit any warnings whe
On Tue, 2013-01-22 at 09:39 -0600, nat...@starin.biz wrote:
> I am actually going to +1 this idea I thought about discussing it, but
> opted out of it because classes are most often in their own file and
> if you need to do some static binding you can do it at the end of the
> file after the class
Am 22.01.2013 22:27, schrieb Clint Priest:
property accessors and magic accessors use the same pre/post function
and logic
So this is the reason for some "magic" behaviour of "property
accessors". Logically "property accessors" may be a subset of "magic
accessors" but not the other way around.
Hi!
> I've wanted a binary PKBDF2() function into PHP for a very long time and
> didn't want to wait for 5.5 release.
>
> Get the patch from:
> http://blog.hqcodeshop.fi/archives/11-Back-ported-hash_pbkdf2-from-PHP-5.5.html
This would look good as an extension, I think. It's much easier to
ins
On 01/22/2013 01:27 PM, Clint Priest wrote:
In terms of cost of maintenance, I was under the impression that
since I wrote it, I would be maintaining it which is why I applied
for and you approved a VCS account for me.
The concern is historical and not personal. Frequently the long-term
cont
On Jan 22, 2013, at 6:00 PM, Christopher Jones
wrote:
> On 01/22/2013 01:27 PM, Clint Priest wrote:
>> In terms of cost of maintenance, I was under the impression that
>> since I wrote it, I would be maintaining it which is why I applied
>> for and you approved a VCS account for me.
>
> The co
Rasmus,
If you look at the split in voting you will notice it is
> pretty much split along the lines of the people who have to maintain
> this code vs. the people who would like a shiny new feature.
>
I pulled some numbers, and this isn't really the case.
Based off of commits from the past year
On 01/22/2013 04:41 PM, Anthony Ferrara wrote:
> Rasmus,
>
> If you look at the split in voting you will notice it is
> pretty much split along the lines of the people who have to maintain
> this code vs. the people who would like a shiny new feature.
>
>
> I pulled some numbers, and
Rasmus,
Now do 5 or even 10+ years and commits to Zend and APC. We are talking
> about a core language feature here, so commits to the code most affected
> is what you should be looking at and when I talk about maintenance I
> talk about code we are fixing 10 years from now. Commits in the past
>
First of all, let's not call this 'magic'.
Static initializers aren't any more magical that object constructors.
johan...@php.net wrote:
> Adding an __init method as you wish will just add complexity and gain very
> little.
> class A {
> public function __init() { echo __CLASS__; }
>
On 01/22/2013 07:20 PM, Dmitri Ravazin wrote:
> hey, here's an idea. Let's drop class autoloading 'magic' as well,
> because it has all the same 'problems' that you've just described.
> It loads things at 'completely arbitrary' times, it's complicated, and
> it surely makes reading code 'too hard'.
41 matches
Mail list logo
