On Mon, Jan 21, 2013 at 7:54 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
* 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.
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
On 2013-01-18, Stanislav Malyshev s...@php.net wrote:
Commit:33b104c778c5c0e5446671397aaddd66efa4a7bc
Author:Stanislav Malyshev s...@php.net Mon, 14 Jan 2013
00:06:09 -0800
Parents: f63a9f6c11c05aa76158b6cae0e05340d303a6af
Branches: PHP-5.3 PHP-5.4 PHP-5.5 master
Link:
On 2013-01-19, Xinchen Hui larue...@php.net wrote:
Commit:f7b99c481d0a943d922e99ad9afa82c45193030e
Author:Xinchen Hui larue...@php.net Sat, 19 Jan 2013 17:01:57
+0800
Parents: e23fca8910b96f1c3bb26c6582c17c92fd6f2f7a
Branches: PHP-5.5
Link:
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
On Tue, Jan 22, 2013 at 4:21 PM, David Soria Parra d...@php.net wrote:
On 2013-01-19, Xinchen Hui larue...@php.net wrote:
Commit:f7b99c481d0a943d922e99ad9afa82c45193030e
Author:Xinchen Hui larue...@php.net Sat, 19 Jan 2013 17:01:57
+0800
Parents:
On Tue, 22 Jan 2013 09:38:11 +0100, Stas Malyshev smalys...@sugarcrm.com
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
On 22 January 2013 01:08, Clint Priest cpri...@zerocue.com 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
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:
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 les...@lsces.co.uk
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.
On 22 January 2013 08:15, Lars Schultz lars.schu...@toolpark.com 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); }
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;
@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
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 Boere
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?
@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
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
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
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
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 no
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
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
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 and the
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 ras...@lerdorf.com 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
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
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
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
install
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
On Jan 22, 2013, at 6:00 PM, Christopher Jones christopher.jo...@oracle.com
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
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 this
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.
?php
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
