Re: [PHP-DEV] [VOTE] Alternative typehinting syntax for accessors
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.
Yes, that's a good point. One can't see this proposal as an introduction of
strict typing, that fully guarantees that the property has one type and one
type only. The typehints are there to help the programmer find mistakes. If
he assigns a wrong type, then he'll get an error. But yes, it will break
down if he actively tries to work against the system. If you start
modifying unserialization input and stuff like that, you will be able to
work around this. Just like you can also work around the method typehints
if you feel like it. I still find them useful.
* The benefits are minimal. The only real benefit is cutting maybe two
lines of code in an indisputably common scenario.
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;?
Thanks,
Nikita
Re: [PHP-DEV] [VOTE] Alternative typehinting syntax for accessors
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 agree;) If accessors get through, I'd rather have this alternate
syntax. The other looks like a typo. I don't get to vote though...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: com php-src: fix bug #63462 (Magic methods called twice for unset protected properties): NEWS Zend/tests/bug63462.phpt Zend/zend_object_handlers.c
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: http://git.php.net/?p=php-src.git;a=commitdiff;h=33b104c778c5c0e5446671397aaddd66efa4a7bc Log: fix bug #63462 (Magic methods called twice for unset protected properties) this appears to break tests/classes/unset_properties.phpt on 5.5 branch, can you please look into this? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: com php-src: Fixed bug #64007 (There is an ability to create instance of Generator by hand).: NEWS ext/reflection/php_reflection.c ext/reflection/tests/bug64007.phpt
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: http://git.php.net/?p=php-src.git;a=commitdiff;h=f7b99c481d0a943d922e99ad9afa82c45193030e Log: Fixed bug #64007 (There is an ability to create instance of Generator by hand). Use get_constrctor instead of access of the ce-constructor directly please note that this breaks ext/pdo/tests/pdo_036.phpt on the 5.5 branch. Please take a look! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: com php-src: fix bug #63462 (Magic methods called twice for unset protected properties): NEWS Zend/tests/bug63462.phpt Zend/zend_object_handlers.c
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 unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: com php-src: Fixed bug #64007 (There is an ability to create instance of Generator by hand).: NEWS ext/reflection/php_reflection.c ext/reflection/tests/bug64007.phpt
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: e23fca8910b96f1c3bb26c6582c17c92fd6f2f7a Branches: PHP-5.5 Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=f7b99c481d0a943d922e99ad9afa82c45193030e Log: Fixed bug #64007 (There is an ability to create instance of Generator by hand). Use get_constrctor instead of access of the ce-constructor directly please note that this breaks ext/pdo/tests/pdo_036.phpt on the 5.5 branch. Please take a look! Hey: fixed thanks :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: com php-src: fix bug #63462 (Magic methods called twice for unset protected properties): NEWS Zend/tests/bug63462.phpt Zend/zend_object_handlers.c
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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] References in rfc:propertygetsetsyntax
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 get{}.
How about pass-by-reference for set{}?
It works, it was simply not included in that section, which it now is:
Documented in the references section:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2?#references
Normally, a function definition dictates this.
But if $value is already passed, a reference to it ($value) is not
going to be referencing the external variable surely?
Whilst objects are always passed by reference (I assume this is still
the case for this rfc and I can see no reason why it isn't), and I
think I can see the sort of issues that setting an accessor to a
reference (binding the value of a property in this class to something
external to the class - yeah - just eek!), is this an issue?
Will users _want_ ...
set($value){ $this-externally_linked_var = $value; }
I'm not expecting any changes to anything, just looking for clarification.
Regards,
Richard.
--
-Clint
Brilliant. Thank you.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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/propertygetsetsyntax-v1.2#voting 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 have voting rights. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
@Lester seems pretty much opt-in to me :) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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. Regarding your other mails you are stuck with 5.2 anyway ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [VOTE] Alternative typehinting syntax for accessors
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); } looks pretty ugly/unclear compared to
public DateTime $date;?
FWIW: I agree;) If accessors get through, I'd rather have this alternate
syntax. The other looks like a typo. I don't get to vote though...
I'm not an expert, so I may be getting the wrong end of the stick.
If you type hint the property, you cannot supply anything but that
type when you set it?
Where as, if you type hint the set parameter, you can supply that
type, and have the set method extract/perform whatever is required and
assign that result to the local property, which may be of a different
type. I would assume that the property has it's own docblock to
reflect the stored type.
Of course, I certainly see a bad case of confusion being presented
here if the stored type and the set type are different. And it would
seem that type hinting the property would solve this, but you know
developers will always want to get around blocks, is there any
sensible use case for having type hinted set() parameter as well as
type hinted property?
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] __init magic method
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;
static function init () {
// Create $bar with expressions...
self::$bar = $bar;
}
}
Foo:init();
A custom autoloader could of course anticipate this but with systems like
composer that have a shared autoload, it'd be nicer to use those than rely
on a custom loader.
--
Pete Boere
Web Developer
Re: [PHP-DEV] __init magic method
@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://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] __init magic method
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 Web Developer
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 use it. Regarding your other mails you are stuck with 5.2 anyway ;) No I'm committed now to converting everything to PHP5.4 which given the amount of work involved is going to take a couple of years, but does not give any 'improvement' to the resulting projects. Just as the latest changes will only mean that we need to maintain PHP5.4 versions of libraries to prevent creep if these developments into those libraries. 'Don't use it' is simply not an acceptable argument when things added in one version become more integrated in the next as has happened between php5.2-3-4 and now 5.5 will take this even further. We NEED to nail down a clean base before changing the rules yet again ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
@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 looking for perfection :) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] __init magic method
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 look at this
single file:
?php
class A {
public function __init() { echo __CLASS__; }
}
class B extends D {
public function __init() { echo __CLASS__; }
}
class C {
public function __init() { echo __CLASS__; }
}
class D {
public function __init() { echo __CLASS__; }
}
class E {
public function __init() { echo __CLASS__; }
}
?
What should this print? ABCDE? Then the derived class B is initialized
before the base class D, which might have strange effects and make
debugging hard. So maybe it is ACDEB? This makes the resolution quite
complicated.
On the other hand: You are showing a goos solution, which is clear and
works well. PHP has the global scope, we don't force everything into
classes and then create Java-style static{}-madness.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 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 to be fixed. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 to be fixed. Actually I don't have anything that I find 'critical'. I have perfectly working systems which only break when ISP's switch off PHP5.2 and install 5.3. HIDING warnings is simply the wrong way to handle BC ... We are forced to address these warnings simply because they can become errors in later versions. HAVING disabled the warnings and not addressed them is the critical bit that requires that code is re-writen in every version update! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 getter nor setter. You can
call isset which will return false but unset will emit a warning, yes?
I would think that the above snippet would create a property with all
public, default implementations. I see why it doesn't: it doesn't
permit you to declare only a getter and no setter.
This is just one more reason for me to vote no on this.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] __init magic method
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 to extend
classes and make the code look much cleaner.
@Johannes In your example I'd say it would be ADBCE because I would say it
should work like as if you had each one in it's own file autoloading them.
(also I believe the function would be static)
One of the potential problems I can see is the visibility
(public/private/protected) of the function as it'd likely need to be public
because it could never be auto-executed if anything else.
Software Developer
Nathan Bruer
-Original Message-
From: Johannes Schlüter [mailto:johan...@php.net]
Sent: Tuesday, January 22, 2013 7:04 AM
To: Pete Boere
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] __init magic method
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 look at this single file:
?php
class A {
public function __init() { echo __CLASS__; }
}
class B extends D {
public function __init() { echo __CLASS__; }
}
class C {
public function __init() { echo __CLASS__; }
}
class D {
public function __init() { echo __CLASS__; }
}
class E {
public function __init() { echo __CLASS__; }
}
?
What should this print? ABCDE? Then the derived class B is initialized before
the base class D, which might have strange effects and make debugging hard. So
maybe it is ACDEB? This makes the resolution quite complicated.
On the other hand: You are showing a goos solution, which is clear and works
well. PHP has the global scope, we don't force everything into classes and then
create Java-style static{}-madness.
johannes
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __init magic method
@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.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 22 January 2013 16:39, 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 definition. However, I do believe this idea would make it easier
to extend classes and make the code look much cleaner.
@Johannes In your example I'd say it would be ADBCE because I would say it
should work like as if you had each one in it's own file autoloading them.
(also I believe the function would be static)
One of the potential problems I can see is the visibility
(public/private/protected) of the function as it'd likely need to be public
because it could never be auto-executed if anything else.
Software Developer
Nathan Bruer
-Original Message-
From: Johannes Schlüter [mailto:johan...@php.net]
Sent: Tuesday, January 22, 2013 7:04 AM
To: Pete Boere
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] __init magic method
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 look at this single file:
?php
class A {
public function __init() { echo __CLASS__; }
}
class B extends D {
public function __init() { echo __CLASS__; }
}
class C {
public function __init() { echo __CLASS__; }
}
class D {
public function __init() { echo __CLASS__; }
}
class E {
public function __init() { echo __CLASS__; }
}
?
What should this print? ABCDE? Then the derived class B is initialized
before the base class D, which might have strange effects and make
debugging hard. So maybe it is ACDEB? This makes the resolution quite
complicated.
On the other hand: You are showing a goos solution, which is clear and
works well. PHP has the global scope, we don't force everything into
classes and then create Java-style static{}-madness.
johannes
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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
this happen for 5.5, voting and the specifications are here:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
Thanks,
-Clint
Thanks Clint and Niki for your work. Sorry to respond only now that
the voting process has already started. I usually don't
follow/participate on internals due to the noise and poisoned
atmosphere (but that's a different story). Also thanks Niki for taking
the time to answer all my questions I had about this beforehand.
My main issue with the implementation at hand is the weird way in
which we allow the visibility on the properties to be declared, e.g.
public $foo { get; protected set; }
The visibility keyword on the property is watering down the visibility
semantics. Either the property is public (then it can be set) or it is
not public. I would have much less of a problem with this, if
declaring visibility on a property could only be loosened but not
tightened. That would at least be consistent with how visibility works
with inheritance. It would be much better though to remove the
visibility keyword from the property altogether. It almost never tells
the truth.
This is basically an argument against asymmetrical visibility altogether
which is one of the most useful features of this proposal. I think
there are many use cases where an object wants to be able to emit a
message (value) but not receive one and being able to declare that fact
is important.
I understand the purpose and utility of having different levels of
visibility. I am not argueing against that. I am argueing that putting
the visibility on the property does not give accurate information about
the property's visibility itself.
Contrived Example: doing just public $foo (Traditional Property) means I
can access the property from everywhere directly. But doing public $foo
{} (Guarded Property) means I cannot access the property *at all*. So we
went through full access to no access just by adding curly braces.
Likewise, private $foo { public get; public set; } is not private at all.
When the visiblity only applies to declared accessors we should just
declare in on the accessors only. That makes for better semantics. After
all, it's a guarded property, which already implies that it is hidden
behind accessors and thus non-public.
Removing the visibility keyword from the property altogether would
also remove the purported default visibility that is applied to the
accessors. I say purported because doing
public $foo { get; protected set; }
will also change the unset accessor to protected, which makes perfect
sense when you think about it but is completely unobvious when the
declaration claims the default visibility of all accessors to be
public. The default visibility of isset is that of get and the default
visibility of unset is that of set instead.
To add to the confusion, doing
public $foo { get; protected set; public unset; }
WILL work and change the visibility of unset back to what the property
claims it is. This should not be necessary when visibility on the
keyword defines the default visibility. I guess it's safe to say that
having the visibility on the property does very little to express
anything meaningful about the property or the default visibility of
*all* the accessors.
Perhaps this is just a documentation problem in that somewhere the
implication that public applies to all accessors when it should really
say that it applies to all declared accessors.
Yes, that should be stretched. I think the final documentation should
also strongly emphasize that Guarded Properties is an entirely new
concept and not some extension to Traditional Properties or to Magic
Methods. We should prevent people from trying to map these new Guarded
Properties onto their existing mental models of how Traditional
Properties or Magic Methods work.
It is perfectly logical that when you cannot set a value, then you
cannot unset a value.
Defining what you have done above is declaring that you want to allow
people to get or unset the value, but not set it directly. This makes
sense in some usage scenarios. As an example, perhaps $foo represents
an internally generated id which is generated on the first call to the
getter, you don't want outsiders to specify the id, but you're okay with
having it unset so that a new one can be generated with the internal
generation mechanics on the next get request.
As an aside, your previous example can also be declared like this:
public $foo { get; protected set; unset; }
unset is explicitly declared and implicitly implemented and is public,
isset would be implicitly declared and implicitly implemented and follow
the visibility of the
[PHP-DEV] hash_pkbdf2() back-ported from PHP 5.5 into PHP 5.4.11
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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 specifications are here: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting 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 have voting rights. 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 ongoing maintenance and potential issues for opcode caches as well. 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. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] send/recvmsg() wrappers in ext/socket
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. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 in terms of ongoing maintenance and potential issues for opcode caches as well. 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 did a bit of testing with APC today and here is what I came up with: https://gist.github.com/4597660 It adds the logic for copying the accessor functions in my_copy_property_info*. This seemed to do the trick in my testing, but I don't really know APC, so I can't judge whether it might require further changes. Thanks, Nikita
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 have voting rights. 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 ongoing maintenance and potential issues for opcode caches as well. 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. Hey Rasmus, With all due respect, I think you missed the post where Nikita Popov analysed two of the biggest PHP based frameworks around, Symfony (Standard) and Zend Framework where he found that there were 3,805 and 4,080 functions which served as a getter or a setter. I do not think his analysis even included any usage of __get() or __set(). Here is his original gist of his analysis: https://gist.github.com/3884203 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. Lastly, I'm not sure if you have looked over the code, but a very large amount of duplicate code has been cleaned up and centralized, both property accessors and magic accessors use the same pre/post function and logic. I can honestly say that adding the feature to the project would *improve* the code base. -Rasmus -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 when
interpreted, but the $foo property has no getter nor setter. You can
call isset which will return false but unset will emit a warning, yes?
This is correct except in the case where you are inheriting the
property. The above, on it's own class would be pointless.
I would think that the above snippet would create a property with all
public, default implementations.
If you are looking to create a public property with default
implementations, the following will suffice and has for a long time:
public $foo;
I see why it doesn't: it doesn't
permit you to declare only a getter and no setter.
Not sure what you mean here, you can declare a property with a getter
and no setter, such as:
public $foo { get; }
Which allows the property to be read, but not written, this is what the
asymmetrical access is about.
This is just one more reason for me to vote no on this.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] __init magic method
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 definition. However, I do believe this idea would
make it easier to extend classes
How so?
and make the code look much cleaner.
Thankfully that's subjective. Some people prefer explicit information
which can easily be read over magic, though.
@Johannes In your example I'd say it would be ADBCE because I would
say it should work like as if you had each one in it's own file
autoloading them. (also I believe the function would be static)
In other words: It is called at completely arbitrary times. Which makes
reading code hard as well as making the implementation more complex
(dependency detection)
Mind that your order requires the engine to delay initialization of B
and C (and E) till D is found. And then go back. That's why I listed the
version with B in the end, that's a tiny bit simpler to implement, but
as hard to explain.
Now for a second game: What does the following script print?
?php
echo A;
class foo { static function __init() { echo B; } }
echo C;
?
ABC? ACB? BAC? I guess the later as the code next to A or C might depend
on the class already.
I hope you see the mess this creates, whereas we nowadays have a
solution which is properly defined and can easily be understood by
everybody, even by people coming from other languages and just trying to
understand the code which was put in front of them.
One of the potential problems I can see is the visibility
(public/private/protected) of the function as it'd likely need to be
public because it could never be auto-executed if anything else.
Such things would be trivial to check during compilation phase.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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. cryptocompress -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hash_pkbdf2() back-ported from PHP 5.5 into PHP 5.4.11
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 an extension from PECL channel that patch recompile whole PHP. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 contributors to PHP have been left to stabilize, integrate (e.g. with APC), and then maintain code that was contributed. I do note appreciate your outstanding perseverance and leadership in working through the RFC process. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 account for me. The concern is historical and not personal. Frequently the long-term contributors to PHP have been left to stabilize, integrate (e.g. with APC), and then maintain code that was contributed. I do note appreciate your outstanding perseverance and leadership in working through the RFC process. Thanks, its been a long hard road for two years. I've wanted to contribute to PHP for years but there was a steep learning curve. I'm personally honored to have been given a VCS account and would like to see the project flourish far beyond where it is presently, I fully intend to be a long term core contributor to this project. I would also like to thank Nikita as he has done a lot with the project as well. Were it not for him, it would not be ready for release. -Clint Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 (since 2012-01-01), here are the raw numbers: No: 1238 Yes: 895 But if you remove the top 2 committing voters (in general, not tied to a list), the numbers even out quite significantly: No: 514 Yes: 456 So I think that point falls somewhat flat... I'm not saying this to raise issues or anything. I just want to point out that the active maintainers are working on both sides of the fence. It's not a maintainers vs the others vote split... Anthony
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 isn't really the case. Based off of commits from the past year (since 2012-01-01), here are the 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 year doesn't really reflect that very well. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
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 year doesn't really reflect that very well. True, but if someone hasn't been active with even a single commit in the past year, I don't think they should be counted as an active maintainer. I ran the numbers back to 2011. And they actually shift more towards Yes: Total Commits: No: 2011 Yes: 1877 All but top 2: No: 996 Yes: 1011 And for 2010 (past 3 years): No: 2455 Yes: 2395 All but top 2: No: 1440 Yes: 1028 This is pointless though. The point is pretty well proven that within reason the activity level of both groups is about even. And when measuring a feature against number of maintainers, I honestly believe that only current active maintainers should count for that ranking. It's not about discrediting prior contributors. Not in the least. I'm not suggesting their votes should count less. I'm not suggesting that they should lose voting rights or anything like that. But to count active maintainers against a list which contains people who's last commit was in 2006 isn't fair. Anthony
[PHP-DEV] RE: __init magic method
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__; }
}
class B extends D {
public function __init() { echo __CLASS__; }
}
class C {
public function __init() { echo __CLASS__; }
}
class D {
public function __init() { echo __CLASS__; }
}
class E {
public function __init() { echo __CLASS__; }
}
?
What should this print? ABCDE?
I don't see any 'complexity' here.
Correct answer is ADBCE, because subclasses might rely on something
that happens in superclass'es initializer. So superclass initializer
should definitely run first.
Now for a second game: What does the following script print?
?php
echo A;
class foo { static function __init() { echo B; } }
echo C;
?
ABC? ACB? BAC? I guess the later as the code next to A or C might depend
on the class already.
And what if I put some echos in my autoload function and make foo
implement A B C and D?
What's that gonna print? And why should I care?
As long as my initializer runs before this class is used (i.e.
before I create an instance or call any static methods or variables),
it makes no difference to me when __init() is called.
Because anything __init() does should be contained to the class itself
(or the parent), and should not be relying on, or changing anything in
the global scope.
Sure, you *can* put your echos there, just like you can put echos in
your autoload functions, or your constructors... It doesn't sound like
a good design choice to me, but it's your code.
But 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'. And the gains are 'very
little', anyway.
You can always load your classes manually with a bunch of require
statements, right?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: __init magic method
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'. And the gains are 'very little', anyway. You can always load your classes manually with a bunch of require statements, right? It is trickier than autoloading because __init() tries to blur the lines between the compile and execute stages if I read your original email correctly. And we have some magic in the compiler that tries to optimize things and resolve as much of the inheritance chain as possible at compile-time to the point where ZEND_FETCH_CLASS opcodes are NOP'ed away(*). I suppose this could still hang off of the the initial ZEND_FETCH_CLASS for a class, but it would definitely get tricky to determine when this would happen. (*) http://lxr.php.net/xref/PHP_5_4/Zend/zend_compile.c# -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
