Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On Fri, Jan 11, 2013 at 8:08 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Re the ReflectionProperty::getParentProperty($this, 'foo') suggestion,
is this supposed to already get the value of the property (and there
would be an additional method ReflectionProperty::setParentProperty)?
I meant getting the ReflectionProperty class, but getting the actual
value is an option too. Of course, then it should be method on
ReflectionPropertyAccessor, since regular properties don't have this
thing. I'm not sure which is better - it depends on how much this would
be used. We could even not do anything special at all - as I said,
current reflection already has API to allow doing exactly this (well,
after property support is added), even if a bit long-winded.
The current property can be obtained through
EG(current_execute_data)-function_state.function. This holds the
accessor function and the property can be taken from its name. Though
this is obviously all a bit dirty and is probably not a good idea.
Probably better to let people explicitly pass the property name.
I agree. That's why I also mentioned having __PROPERTY__ - this makes
copypasting methods a bit easier since you have less chances of making
typo in property names :)
--
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
I'm guessing this RFC won't make it in PHP 5.5? Too bad since it did
seem like a very nice feature to have.
I don't know if it is very helpful but posting nevertheless. I'm a
C++/Qt/QML/PHP developer and for me the proposed syntax in the v1.2
document makes perfect sense and is intuitive to use. As for the
earlier example about isset...
i'd expect an example like this:
class SomeClass {
public $date {
get;
set(DateTime $date);
}
}
$temp = new SomeClass();
i'd expect isset($temp-date) to return exactly the same as if the
class where defined like this:
class SomeClass {
public $date;
}
I don't know if that issue was already sorted out but i wanted to
share my expectations in that regards.
Will this make PHP 5.5? Or will it be deferred to 5.6?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On 1/13/2013 8:01 AM, Mark wrote:
I'm guessing this RFC won't make it in PHP 5.5? Too bad since it did
seem like a very nice feature to have.
I don't know if it is very helpful but posting nevertheless. I'm a
C++/Qt/QML/PHP developer and for me the proposed syntax in the v1.2
document makes perfect sense and is intuitive to use. As for the
earlier example about isset...
i'd expect an example like this:
class SomeClass {
public $date {
get;
set(DateTime $date);
}
}
$temp = new SomeClass();
i'd expect isset($temp-date) to return exactly the same as if the
class where defined like this:
class SomeClass {
public $date;
}
That's correct, it will.
Furthermore, isset() will never throw an error, even if it would not be
legal to call isset or get (from 1.1 RFC changes).
I don't know if that issue was already sorted out but i wanted to
share my expectations in that regards.
Will this make PHP 5.5? Or will it be deferred to 5.6?
Nikita, Stas and I are working very hard to make it into 5.5, we expect
to propose a vote sometime in the next couple of days.
** Any remaining feedback is appreciated, the RFC is being kept up to
date w/ current understood consensus. **
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] FW: Functionality request/proposal
Hi,
I'm currently interested in two features I'd like to see in PHP; how do I
proceed to request/propose them? I'd be glad to help implementing them as well,
if necessary.
One of them is really simple, but would be helpful to people with different
coding styles
class Test {
public function blabla() {
// ...
} // the interpreter fails if there
// is a semicolon here, although
// some c++ programmers may be used
// to add it
};
And the other one would be multiple return values
function multi() {
return 10, 20;
};
function sum($a, $b) {
return $a + $b;
};
echo sum(multi()); // echoes 30
$x, $y = multi();
echo $y; // echoes 20
Thank you!
Re: [PHP-DEV] PHP-5.5 unpack change broke pecl/pear
On 12/28/2012 01:08 AM, Remi Collet wrote: Le 24/12/2012 04:16, Igor Wiedler a écrit : Hi Internals, When test driving PHP-5.5 I ran into issues with a change of unpack behaviour. Archive_Tar which is used by pecl and pear (`pecl install`) uses unpack with the a format character. On 5.4 it strips trailing NUL bytes, on 5.5 it does not. There is a new Z format character that can be used to get the old behaviour. The point is, this change broke pecl, and will likely break many other things in existence. Anthony has asked me to post to internals, so that you can re-visit the issue and perhaps consider not breaking BC. If you decide that you want to keep the BC break, I will gladly submit a patch for Archive_Tar. See http://pear.php.net/bugs/bug.php?id=19746 Remi. Thanks, Igor Sherif, Are you owning this issue? I assigned bug https://bugs.php.net/bug.php?id=63073 to you in case you are. 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] PHP-5.5 unpack change broke pecl/pear
On Sun, Jan 13, 2013 at 11:35 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 12/28/2012 01:08 AM, Remi Collet wrote: Le 24/12/2012 04:16, Igor Wiedler a écrit : Hi Internals, When test driving PHP-5.5 I ran into issues with a change of unpack behaviour. Archive_Tar which is used by pecl and pear (`pecl install`) uses unpack with the a format character. On 5.4 it strips trailing NUL bytes, on 5.5 it does not. There is a new Z format character that can be used to get the old behaviour. The point is, this change broke pecl, and will likely break many other things in existence. Anthony has asked me to post to internals, so that you can re-visit the issue and perhaps consider not breaking BC. If you decide that you want to keep the BC break, I will gladly submit a patch for Archive_Tar. See http://pear.php.net/bugs/bug.**php?id=19746http://pear.php.net/bugs/bug.php?id=19746 Remi. Thanks, Igor Sherif, Are you owning this issue? I assigned bug https://bugs.php.net/bug.php?**id=63073https://bugs.php.net/bug.php?id=63073to you in case you are. It was discussed on IRC that this change was applied in order to bring PHP's implementation of pack() to be more inline with Perl's implementation (see https://bugs.php.net/61038 for details) and thus why the change was introduced in PHP 5.5 instead of 5.4, which was already final at the time. The BC was taken into consideration, but the manual never specified that this was the defined behavior. So we had made the decision at the time that this BC would be worth taking in 5.5 for bringing the implementations inline. The BC concerns seem to be fiarly limited in in immediate scope to Archive_Tar, which seems to be a trivial patch (see http://pear.php.net/bugs/bug.php?id=19746edit=12patch=archive_tar_php55.patchrevision=1355241213also) and Igor Wiedler seems willing to apply it. Obviously there can more BC out there with people that rely on this behavior in their existing code, but I can not gauge this if I just base it on the number of open bugs in the bug tracker that have to do with pack and PHP 5.5. So in light of these events the plan is to ask that Archive_Tar be patched to resolve the make install issue and remain consistent with the Perl implementation, which also seems consistent with Ruby's implementation of pack. The spec itself seems a bit ambiguous as noted earlier in this thread, but I think PHP will benefit more from being consistent with the other implementations. Please let me know if there are other BC concerns that have not yet come up. 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.htmlhttp://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: [PHP-DEV] PHP-5.5 unpack change broke pecl/pear
Le 14/01/2013 06:57, Sherif Ramadan a écrit : Please let me know if there are other BC concerns that have not yet come up. Please don't forget that php tree comes with pear/install-pear-nozlib.phar This old archive contains Archive_Tar 1.3.7, so should be updated. (I don't know who still use it, Fedora don't use it for a while) Remi. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
