Re: [PHP-DEV] Generics proposal
Hi Sara, any progress with your RFC? Can't wait to see it.
Thanks
Jan Dolecek
juzna...@gmail.com
On Wed, Nov 7, 2012 at 6:41 AM, Sara Golemon poll...@php.net wrote:
Retrying this with reply-to-all. :)
I think it's an awesome moment for PHP and HipHop to work together! :)
I'll summarize what we have so far into an RFC.
-Sara
On Tue, Nov 6, 2012 at 12:50 PM, Lars Strojny l...@strojny.net wrote:
Hey Sara,
can you already show us how your take on Generics would look like? Maybe
this is a good moment for HipHop and PHP to do something together.
Am 06.11.2012 um 04:14 schrieb Sara Golemon poll...@php.net:
Sorry to be late to the conversation, but fwiw, HipHop is adding
Generics (and some other cool things) to our PHP implementation. We
plan to provide a PHP equivalent implementation in the form of a
pre-processor extension which can live in PECL. The implementation
would of course be cleaner if done directly in the engine, but with
APC the performance hit of doing an extra transformation pass should
disappear. Hopefully this satisfies both the want for Java/C++-like
syntax without polluting the language.
-Sara
On Tue, Oct 23, 2012 at 4:21 AM, Etienne Kneuss col...@php.net wrote:
Hi,
On Tue, Oct 23, 2012 at 4:17 AM, Levi Morrison
morrison.l...@gmail.com wrote:
Especially if the ability was afforded to arrays as well (function
foo(arrayBar $array){})...
This would require O(n) runtime tests, I would definitely not go
there.
Actually, it does not require O(n) runtime tests. The solution is
simple: store the type when it is created. Whenever an element is
added, make sure it matches the correct type. All this does is add
some flat overhead.
If you test every time you add one element, that's still O(n) tests
where n is the size of the array, the only benefit is that it is not
checked for each calls to a function. But now we are talking about
attaching non-trivial types to variables, and non-trivial checks in a
lot of places (think references etc..), let's not go there...
I am also supportive of the idea of having generics, but I am not sure
that the work it would take is worth it.
--
Etienne Kneuss
http://www.colder.ch
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars
I'm not able to try it myself at the moment and it's not described in the RFC, so I'd like to ask: Will it invoke autoloading, if the class does not exist (yet)? I think this should be considered. If so, it's not good as it kills lazy-loading. If not so, it we may get errors later than expected. I think these problems deserve discussion. (I'd prefer to keep lazy-loading, since existence of class gets validated by IDE) Regards, JD On Tue, Sep 11, 2012 at 4:39 PM, Ralph Schindler ra...@ralphschindler.comwrote: Hi internals! The ::class resolution proposal had significant discussion in April and I've updated the patch to address issues that came up then. At this point, I've gotten some positive feedback from various places and feel its time to open it up for a vote to internals. RFC: https://wiki.php.net/rfc/**class_name_scalars#votehttps://wiki.php.net/rfc/class_name_scalars#vote PR: https://github.com/php/php-**src/pull/187https://github.com/php/php-src/pull/187 Thanks, Ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reflection to remove final
setFinal is available for both classes and methods, as shown in example in my gist (https://gist.github.com/1621839#file_final_test.php). This should be enough for all possible mocks, as I discussed it with my friends. It is also possible to remove final, create a mock class and then put it back, if someone wants to keep it after mocks have been created. Sorry about my CS, I'll be more careful next time. I wanted to make a proof of concept quickly to try it in PHP. Jan Dolecek juzna...@gmail.com On Tue, Jan 17, 2012 at 12:03 PM, jpauli jpa...@php.net wrote: Just one last word : The patch just adds setFinal() to ReflectionClass. What about ReflectionMethod ? Not very usefull for the mocking purpose, but that would be good for the Reflection API. Julien On Tue, Jan 17, 2012 at 12:00 PM, jpauli jpa...@php.net wrote: +1, I like the idea as well. How didn't we think about that earlier... ? Julien On Tue, Jan 17, 2012 at 11:54 AM, Sebastian Bergmann sebast...@php.netwrote: Am 17.01.2012 11:34, schrieb Pierre Joye: Patch looks good, but coding standard. If there are no objections, I can fix the CS issue and commit the patch to trunk. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- 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] Reflection to remove final
Yes, there always is a reason. But when we test and create mocks, this reasons can go aside. This is the same with ReflectionProperty::setAccessible() etc. They shouldn't be used normally, but in special cases like testing it's necessary. Jan Dolecek juzna...@gmail.com On Tue, Jan 17, 2012 at 2:01 PM, Ferenc Kovacs tyr...@gmail.com wrote: if a class is marked as final, there must be some reason for it to be a final. if you remove the final and extends it, may lead to bad error. reflection should always be used with care. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reflection to remove final
Why did you choose to make the argument to setFinal() optional? setAccessible() doesn't do this. To be honest I didn't check the setAccessible method first. It just seemed natural to me, that $refl-setFinal() makes it final even without true as an argument. Jan Dolecek juzna...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reflection to remove final
Sebastian, thanks for the commit. But actually as I see the tests, I
may have not specified it enough:
ReflectionClass::setFinal(false) removes the final from the class, not
it's methods.
This test case
http://svn.php.net/viewvc/php/php-src/trunk/ext/reflection/tests/ReflectionClass_setFinal.phpt?view=markuppathrev=322390
should have:
final class a { // class is final
public function b() { // method is not
...
}
}
Thanks
Jan Dolecek
juzna...@gmail.com
On Tue, Jan 17, 2012 at 12:28 PM, Sebastian Bergmann sebast...@php.net wrote:
Am 17.01.2012 12:03, schrieb jpauli:
The patch just adds setFinal() to ReflectionClass.
What about ReflectionMethod?
From the patch
+/* {{{ proto public void ReflectionMethod::setFinal([bool isFinal = true])
+ Sets/unsets class as final */
+ZEND_METHOD(reflection_method, setFinal)
+/* {{{ proto public void ReflectionClass::setFinal([bool isFinal = true])
+ Sets/unsets class as final */
+ZEND_METHOD(reflection_class, setFinal)
TL;DR: All is well :)
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
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] Reflection to remove final
This issue seems much more complicated than I thought. We'll need to consider all cases which could cause troubles and have a solution for them. Namely: - rewriting permanent structures for internal classes, which are being kept between requests, must be avoided - races in threading models - rewriting in bytecode caches must be avoided - anything else in mind? I'll try to think about it, but I'm not that experienced with php internals, so any suggestions welcome. Jan Dolecek juzna...@gmail.com On Tue, Jan 17, 2012 at 11:21 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! This doesn't seem right. Correct me if I'm wrong: for internal classes, their data structures are allocated permanently, so I'd say the effects of removing the flag would be permanent (i.e., would affect subsequent requests). And for threaded builds this could cause races between the threads. It'd probably also mess up bytecode caches, since they permanently store class definitions. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Output buffer bug in RC5
Hi guys, I've just downloaded PHP 5.4 RC5 and noticed a problem with output buffering. I filled in a bug report (https://bugs.php.net/bug.php?id=60768) but wanna give you a quick notice, so that it gets fixed before next RC and stable won't be delayed. Test case is attached and works properly in 5.3.9, but the buffer gets replicated in 5.4 RC5. Thanks for having look at this issue. Jan Dolecek juzna...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Reflection to remove final
Hi, reflection is a great tool for testing, but it still misses support for mocking classes/methods marked as final. I created a small patch https://gist.github.com/1621839#file_php_finals.patch, examples how to use it https://gist.github.com/1621839#file_final_test.php and wrote a short article explaining it: http://blog.juzna.cz/2012/01/mock-vs-final-fights-in-testing/. Can you include it into svn pls? Thanks Jan Dolecek juzna...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
Someone said that it won't be that easy, because functions are
searched within a namespace first and when they don't exist there,
then are called from global namespace.
Example:
?php
namespace example;
echo substr('Test', 1, 1);
When calling function substr, Zend engine first tries to find function
example\substr. If such function doesn't exist, it tries just substr
which is found and called. Thanks to this lookup, we don't need to
escape all function calls with backslash prefix.
?php
echo not_found(1);
When trying to autoload a function, which one should be auto loaded?
example\not_found or not_found?
Similar situation is with constants, because of BC a non-existing
constant must result in string with the same value as constant's name.
?php
var_dump(MY_CONSTANT); // string(11) MY_CONSTANT
Some programmes rely on it (though it's not recommended) and calling
autoloader everytime would add significant load to such apps.
Jan Dolecek
juzna...@gmail.com
On Fri, Aug 12, 2011 at 11:31 AM, Ferenc Kovacs tyr...@gmail.com wrote:
On Fri, Aug 12, 2011 at 12:12 PM, Sebastian Krebs
krebs@googlemail.com wrote:
Hi,
2011/8/12 Ferenc Kovacs tyr...@gmail.com
On Sat, Aug 6, 2011 at 2:24 PM, Ryan McCue li...@rotorised.com wrote:
Ferenc Kovacs wrote:
I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.
Shouldn't the default type be T_CLASS|T_INTERFACE?
sorry for the late reply.
judging from your reply and the conversion on irc with Etienne, I
think that the usage of the token constants are ambiguous(we have
different token constants for classes and interfaces as you mentioned
for example).
originally I chose this because this would be fully backward
compatible, but now I think that we should add new constants.
what do you think?
From the users point of view I don't care. It's just another constant. Also
constants like
SPL_AUTOLOAD_CLASS
SPL_AUTOLOAD_FUNCTION
SPL_AUTOLOAD_CONSTANT
seems to be more obvious, because it reflects, that it belongs to
spl-autoload.
imo from the users point of view your suggested constant names are
much better, plus the T_* constants are provided by the tokenizer
extension, which AFAK could be disabled compilation time, and by
itself would be a bad idea to couple the two extension.
so +1 for your suggestion, I will update the RFC, and check out how
hard would be to create a patch.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
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
[PHP-DEV] What happened to error details in stat
I remember that if error happened in stat- related functions, error message contained also system errno and message, like in following line: Warning: fileatime(): Stat failed for /tmp\lost+found (errno=2 - No such file or directory) in /home/rfresh/public_html/whosonline_form.php on line 93 But now it says only: Warning: filesize(): stat failed for non-existing-file in shell code on line 1 Why PHP doesn't report reason of stat failure anymore? It makes solving such problems much more difficult, as I don't know why stat failed. Note: first error message was copied from a forum post written in 2005. Jan Dolecek juzna...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] parsing break and continue statements
I guess to get a clear error message, because this is a BC change. Many people would wonder why working scripts are causing parse errors after upgrade of php. Makes sense to have error messages as clear as possible ;) Jan Dolecek juzna...@gmail.com 2011/7/29 Kiyoto Tamura owenes...@gmail.com: Hi Johannes, Thanks for your reply :) What I meant was that why does the parser still accept any expression after T_BREAK/CONTINUE and defer the error check to zend_do_brk_cont? Isn't it clearer to only accept if the expression following T_BREAK/CONTINUE is a positive integer (if there is any expression at all)? Kiyoto 2011/7/28 Johannes Schlüter johan...@schlueters.de: On Thu, 2011-07-28 at 16:10 -0700, Kiyoto Tamura wrote: Hi, I am new to the PHP internals, and I was just looking through the code related to parsing break/continue statements. It looks that as of PHP 5.4, Zend/zend_language_parser.y accepts both T_BREAK expr and T_CONTINUE expr and check to make sure expr is a positive integer in the function zend_do_brk_cont. Doesn't it make more sense to replace T_BREAK expr with T_BREAK positive integer (the same goes for the continue statement)? T_BREAK expr allows things like $foo = rand(...); break $foo; but we've dropped that for performance reasons in 5.4. johannes Thanks in advance! kiyoto -- 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] Weak References
Thanks Etienne, I was waiting for this for a while! I wrote a blog post how to get best benefits from weak references: http://blog.juzna.cz/2011/08/weak-references-in-php/ Perhaps this will help showing people what are they good for. And thanks to PECL extension I hope we can start using them in my company very soon in our extension of Zend_Db. Jan Dolecek juzna...@gmail.com On Wed, Aug 3, 2011 at 3:29 PM, Etienne Kneuss col...@php.net wrote: Hi, http://pecl.php.net/package/Weakref has been created, and the standalone code should compile fine (I checked for 5_3 only but everything should be smooth for 5_4/trunk) The next planned addition is a StrongRef class, following the exact same interface as WeakRef only that it is always valid and get() always return the ref. The reason for it is that code can switch between the two transparently. Best, On Wed, Aug 3, 2011 at 14:49, Hannes Landeholm landeh...@gmail.com wrote: Good idea. I will see what I can do when I get time. ~Hannes On 3 August 2011 12:32, Pierre Joye pierre@gmail.com wrote: hi Hannes, I would suggest to still update the RFC with the various very instructive comments and example use cases you use in this thread. Doing the same in the long run should help as well to understand the goals, implementations, etc., for the pecl users or for the 2nd attempt to get it in the core, if still desired. Cheers, On Wed, Aug 3, 2011 at 12:25 PM, Hannes Landeholm landeh...@gmail.com wrote: Hello, We had a healthy discussion around WR and I have been able to express my concerns. The consensus is clearly to put it in a PECL extension so I think this discussion should move on to the practical matters of doing this. I suggest aborting the vote and changing the RFC state to something like Transfered to PECL. ~Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- 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]strn(case)cmp supporting a negative length as its third paramter
This would make perfect sense with constant strings and constant length, when using variables this may lead to some magic bugs, which would be normally reported as E_WARNING. Not sure if it's a good idea :( Jan Dolecek juzna...@gmail.com On Mon, Aug 1, 2011 at 7:40 AM, Laruence larue...@php.net wrote: Hi everyone: plz vote for this : strn(case)cmp supporting a negative length as its third paramter RFC: https://wiki.php.net/rfc/strncmpnegativelen#vote if you have any objection, plz write back. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- 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
