[PHP-DEV] Trait vs magic constants (bug #61033)
Hi Internals after quite a long time,
There is an issue in the tracker (#61033 and somewhat related #64239)
about magic constants behaviour in aliased trait methods. Stefan
classified #61033 as a "feature not a bug" however he suggested to start
a discussion about it.
So here's the case: how to get current running method name when in an
aliased trait method:
trait T {
public function method() {
// __FUNCTION__ is "method"
}
}
class C {
use T { method as m; }
public function method() {}
}
This is all nice and dandy but imagine (among other things) that you
want to return a callback to itself from such a method. How would you go
about it?
Returning [$this, __FUNCTION__] would be most obvious but it's obviously
not what we want. Apart from using debug_backtrace (which has it's own
issues; #64239 being one) I don't see any way of doing it.
So: is this a feature or a bug?
And if it really is a feature then either we need another magic const
(like suggested in #64239) or (preferably IMO) a method to resolve
method name at runtime (a counterpart to get_called_class() - say
get_called_method()).
Cheers
Marcin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug in namespaces and type hints
Hi, recent change in namespace code introduced new bug, please consider: triggers "Fatal error: Default value for parameters with a class type hint can only be NULL" where the same w/o namespace definition works as expected (no error). this is tested with currently newest snap: 2008.11.09 23:30 (UTC) I haven't filed bug report for this yet i'll do it if required. TIA for quick fix ;-) Marcin Kurzyna -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
Greg Beaver wrote:
>
> namespace foo\classes;
> use sneaky\devil as foo;
>
> class buh extends foo\stuff {}
> \\ this extends sneaky\devil\stuff. oops... should have used \foo\stuff
> ?>
accualy I have a question about this if i may: why doesn't the use statement
fall under the same resolution rules as general code? that is why foo isn't
foo\classses\sneaky\devil?
personally i'd find this much more consistent if *anything* below namespace
declaration was relative to it. and i could always use absolute declaration
explicitly if i'd require it:
resolves as A == \foo\bar
use \bar as B; /// ->resolves as B == \bar
?>
TIA
m.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
"Stan Vassilev | FM" wrote: > For me the only way to make it clear to both humans and parsers alike is > the filepath semantics, in all places, including use. It's not perfect, > there's no completely problem-free solution, but "prepend \ for absolute > path" is able to become muscle memory, while other mixed solutions I've > seen are more confusing and require more thinking: "wait in this context > what was what?". My point exactly. This was a real pain in the ass while converting from old to new resolution rules (though I now this is a one-time example). However i was explaining the new resolution rules to my co-workers recently and it was aparent the context dependant resolution isn't clear, while understanding: "it's always relative to current namespace" is simple and easy. Also most people are familiar with filepath semantics so there is a obvious point of reference (and confusion when it's not consistent). > But this introduces a new keyword: nameof, which could clash with > function/class/constant "nameof" in existing source code. I could suggest [...] > But it's definitely in-your-face issue while using namespaced code. I'm not shure how big of a problem "nameof" clashing would be, however a way to get fully qualified name is a nessesity in my opinion - i strugle with this in my framework too. Gregs suggestion of __NAMESPACE__ concatenated solution (if i understand it correctly) isn't one accualy because __NAMESPACE__ resolves to current namespace; and "typeof" might (and probably usually will) be used on aliased classes not nessecerely from current namespace. m. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
David Grudl wrote: > Why? I have developed framework using PHP namespaces and studied Zend > Framework source codes and result is: if we use the new resolution rules > (1), than in nearly all cases developers must prefix class names with \, > only in few cases prefix is not required. Why? Because usually classes > in more nested namespaces extends classes in less nested namespaces. If > you don't believe, look in framework sources :-) > > So, resolution al?? 1) is nearly in all cases pain and in few cases nice, > resolution al?? 2) is nearly in all cases nice and in few cases not too > nice. true, however i have a counter example: classes from more general namespace that use further nested classes (think some kind of behaviour and different drivers/plugins for example). so while it's true that more nested classes usually extend the less nested ones it also common for more generic code to use it's namespace descendants. in sutch condition possibility to use just the remaining namespace part is a big help and i'd say it's usage would be more comon than single "extends" at class definition where you're obligated to supply FQN [1]. > > Furthermore, resolution al?? 1) means, that namespace named foo\stuff is > fiction - there is only namespace named \foo\stuff. Lets use \foo\stuff > everywhere: i second that (at least when FQN is used) - would provide more consistency. m. [1] FQN: fully quallified name -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Closures serialization
Hello internals and a happy new year. I've been meaning to ask this for some time now: why aren't closures serializable? The only on-list discussion about this that i've found is: http://marc.info/?l=php-internals&m=119837318407795&w=2 Personally i'd find serialization of closures very useful (think serializing of callback arrays, serialization of objects that acquired closure somewhere during execution, etc) Also i find that being unable to serialize closure introduces a slight inconsistency. It was possible to serialize "is callable" type (plain array/string) whereas now it's not always the case[1] so programmers have to be aware of it when using some kind of "register callback" behavior. So to my question: why aren't closures serializable? Is it a design choice or implementation issue? I've looked at both zend_closure.c (for closure implementation) and var.c (for serialization) but didn't see anything that could suggest either way. Now for some wild guessing: In the internals post mentioned above it's stated that annonymous function name is along the lines of hashfunction(__FILE__) and per_file_counter; i understand that it's deterministic, and so if i were to serialize just this id (as sting) it should be possible to track back to the actual code after deserialization? i imagine that it would require (in simple terms) getting the original file and "executing/assigning" n-th per_file closure. It should be even simpler when done in the same request and/or with opcode caches where just the id should be sufficient to get the original opcodes and execute. I'll look some more into it myself but i'm not that fluent in C to provide quality patch (not to mention zend api). I'd like to know your opinion whether this could be implemented though. TIA Marcin Kurzyna [1] While it was possible to serialize an array of callbacks before it's impossible with closures assigned, see example below: http://aquarion.hq.crystalpoint.pl/public/php-internals/closure-serialization.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures serialization
Hi Marcus, You would need to provide a c level serialization that stores the $this pointer (the easy part) and the zend_function member (not easy). The second part requires storing of all static variables, which again is pretty easy but it also requires to store the function itself, which in case of a user function probably only means the string but then at the time of serialization you only have the compiled opcodes. So you would need APC to serialize the opcodes, which is not yet implemented. Alternatively you could save the implementation string somewhere. And serialize that and compiling it upon unserialization. If you're more interested, c level serialization with multiple serialization inputs is used for: SplObjectStorage::serialize() / unserialize(). thnx for your insight. i've looked at SplObjectStorage::serialize and it seems pretty straight forward - this shouldn't be a problem. as you said it's saving the zend_function member that is tricky. i thought i'd go with saving function string and recompiling it as you suggested (i don't want to mess with APC although i find the idea of opcode serialization much more appealing). anyway it's proving itself, well... tricky ;-) i'm thinking about hooking into zend_do_beging_lambda_function_declaration and saving all until zend_do_end_function_declaration, but i haven't tried that in practice yet (not even sure how to do this at the moment - i'll get to it tonight). thnx marcin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures serialization
Hi Marcus, You would need to provide a c level serialization that stores the $this pointer (the easy part) and the zend_function member (not easy). The second part requires storing of all static variables, which again is pretty easy but it also requires to store the function itself, which in case of a user function probably only means the string but then at the time of serialization you only have the compiled opcodes. So you would need APC to serialize the opcodes, which is not yet implemented. Alternatively you could save the implementation string somewhere. And serialize that and compiling it upon unserialization. If you're more interested, c level serialization with multiple serialization inputs is used for: SplObjectStorage::serialize() / unserialize(). thnx for your insight. i've looked at SplObjectStorage::serialize and it seems pretty straight forward - this shouldn't be a problem. as you said it's saving the zend_function member that is tricky. i thought i'd go with saving function string and recompiling it as you suggested (i don't want to mess with APC although i find the idea of opcode serialization much more appealing). anyway it's proving itself, well... tricky ;-) i'm thinking about hooking into zend_do_beging_lambda_function_declaration and saving all until zend_do_end_function_declaration, but i haven't tried that in practice yet (not even sure how to do this at the moment - i'll get to it tonight). thnx marcin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Closures and __FUNCTION__
Peter Danenberg pisze:
Quoth Justin Martin on Pungenday, the 30th of Discord:
If I recall correctly, you can use the 'use' keyword.
Thanks, Justin; that occurred to me, too. But the following results in
"Notice: Undefined variable: factorial":
$factorial = function($n) use ($factorial) {
if ($n == 1)
return 1;
else
return $n * $factorial($n - 1);
};
print $factorial(3);
and eventually "PHP Fatal error: Function name must be a string."
This is correct.
See: in the first example you were referencing previously defined $foo
(which at the moment of first reference was NULL). It was only later
replaces with closure itself but it worked because of the reference.
On the other hand when you copy variable you try to use undefined
$factorial (thus the notice). It is because at the moment of "using" the
variable it's undefined. Only later it becomes our closure, however then
it's after evaluation of use.
Although this is probably more a generals topic. The lack of
__FUNCTION__ inside the closure is however something i'd like to hear
more about.
Any word on this from the devs?
TIA,
Marcin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Lars Strojny wrote: >> Not like they will be listened to unless they are "commiters". > > They are heard. The issue is, as always in programming, you want to do [...] > maintainability, safety and security. I'm not saying the core > contributors are always right, but there being core contributors is an > evidence. Yes, but in this and some other cases (i've been reading internals for quite some time now) it's just a question of wether the majority with karma likes or dislikes (as in i like yellow more then red) certain feature. The short array syntax isn't a technical issue or dificulty as was discussed and acknowledged. It wasn't ment to replace explicit array() nor does't it impose noticable performance loss. And it's not like there wasn't a will to write a patch as in some other cases - it's just a metter of maitanance when the 'commiters' in general don't like it (as noted in conclusion in wiki). So in the end it's just a matter of veto power of those with karma over those without. Which is (in most cases) the right way to go as illustrated by the Company Argument. What i don't understand is why sutch a non intrusive feature had to go through sutch passionate discussion and voting process. There are commiters who like it (more then one) and probably could maintane it (i guess it wouldn't be mutch work as it's mostly a one time parser change binding to already existing and maintained functionality; though i might be wrong here). If so why couldn't this go in and just be ignored by those who don't like it? It's not like anything wolud change for them. Any way - it's just my thoughts and as the proposal was already declined i don't see mutch more reason for discussion. I think it will come back in couple months again though as most things with out really clear consensus. m. ps. it polite to say hi when entering a room, so: hi. -- Marcin Kurzyna - Software Engineer @ CrystalPoint here as "a voice from userland developers(tm)" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
