Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()
Hi,
On 14/02/2015 21:23, Matteo Beccati wrote:
On 14/02/2015 16:34, Philip Sturgeon wrote:
On Sat, Jan 31, 2015 at 8:27 PM, Andrea Faulds a...@ajf.me wrote:
I think the more important issue is the conflict with the
ReflectionTypeAnnotation RFC, which proposes something similar to
what was originally part of the Return Types RFC:
https://wiki.php.net/rfc/reflectionparameter.typehint
That's the reflection support I was talking about! I knew there was
something, but I just couldn't find it in the RFCs themself.
I've been playing a little bit with Sara's work (as you might have
noticed if you follow php-cvs - sorry again!) and got it working with
the scalar type hints branch:
https://github.com/mbeccati/php-src/tree/scalar_hints_with_reflection
It's still missing the scalar part and possibly an easy way to get the
class name as Phil suggests.
Thanks to my cats waking me up too early on a sunday morning, I've
rebased Sara's patch to current master and updated it to support return
types:
https://github.com/mbeccati/php-src/commits/reflection.typehint
The new methods are:
* ReflectionFunctionAbstract::hasReturnTypeAnnotation()
* ReflectionFunctionAbstract::getReturnTypeAnnotation()
* ReflectionTypeAnnotation::isInstance()
The latter should fulfil Phil's getClassName() purpose, albeit it's much
more verbose:
function get_name (ReflectionParameter $rp) {
if ($rp-hasTypeAnnotation()) {
$ra = $rp-getTypeAnnotation();
if ($ra-isInstance()) {
return (string) $ra;
}
}
}
I've also added scalar support in:
https://github.com/mbeccati/php-src/commits/scalar_hints_with_reflection
which has:
* ReflectionTypeAnnotation::isScalar()
I believe that both isInstance/isScalar would probably apply to
ReflectionParameter too, unless the old way is supposed to be deprecated.
@Phil I apologise it I hijacked your RFC, but I think that having just
ReflectionParameter::getClassName() falls a bit short IMHO, especially
with return types.
@Andrea, @Sara I hope you don't mind ;)
Cheers
--
Matteo Beccati
Development Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Design by Contract
Hi François
-Ursprüngliche Nachricht-
Von: François Laupretre [mailto:franc...@php.net]
Gesendet: Sonntag, 15. Februar 2015 11:43
An: 'Robert Stoll'; 'Yasuo Ohgaki'
Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav Malyshev'; 'PHP Internals'
Betreff: RE: [PHP-DEV] Design by Contract
De : Robert Stoll [mailto:p...@tutteli.ch]
The theory is actually quite simple. Roughly it says that if you use a
type hint of a certain class then you can rely on all
pre/post-conditions of this class even if a sub-class is passed. Hence
the sub-class cannot have more restrict conditions.
I guess from the example above it should be clear why D has
implemented it this way
OK. Thanks for your explanations.
What I meant is that, while I understand the theory, I don't understand the
reason *why* it must be done this way.
An additional point is that, IMO, It is impossible for a software to enforce
the theory and check that a set of conditions is
more or less restrictive than another one, except analyzing them, which is
far beyond our possibilities. So, IMO, we can just
give it as a convention, which is quite poor. That's why I preferred to use
another logic. But I would like to know if it won't
bring other problems later.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
Unfortunately, I am not familiar with Eiffel or D, so I am just assuming and
cannot really give you the specific reason behind the design decision.
Having LSP-safe contracts allow that a type checker has do perform a conformity
check only once and not for each case which is most probably way to slow and
further cannot guarantee contract-safety at compile-time anyway (Eiffel and D
are both statically typed).
Considering my example again, this time with some kind of static typing:
class A{
function foo(int $x){
pre($x 100);
}
}
class B extends A{
function foo(int $x){
pre($x 50); // less restrictive, that's fine
}
}
class C{
function foo(int $x){
pre($x 150); //more restrictive that's not allowed
}
}
function foo(A $a){
$a-foo(101); // that is ok as long as LSP is not violated
}
foo(new A()); //that's fine
foo(new B()); //fine as well
A $a = new C(); //the type checker thinks $a is of type A, does not know that
it has actually type C
foo($a); //not possible for a type checker to see the violation
With the LSP rule in place the type checker does not need to verify the
function call foo since everything of type A will conform anyway.
Makes sense no? But as I said, I am just assuming. Someone familiar with Eiffel
or D can probably give some insights.
I totally agree with you that such a check is not feasible for PHP, a
dynamically typed language in general respectively.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Broken link in PHP manual
Alain Williams wrote: http://php.net/manual/en/features.gc.collecting-cycles.php has a reference ''Concurrent Cycle Collection in Reference Counted Systems'' to http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf The PDF is no longer there. This has already been reported as bug #68890[1], and there is a patch available. IIRC the patch has been also submitted to PhD O.E. [1] https://bugs.php.net/bug.php?id=68890 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Broken link in PHP manual
http://php.net/manual/en/features.gc.collecting-cycles.php has a reference ''Concurrent Cycle Collection in Reference Counted Systems'' to http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf The PDF is no longer there. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
On 15 February 2015 at 02:46, Andrea Faulds a...@ajf.me wrote: Hi everyone, I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker. Putting it to a vote, finally, means I can stimulate further discussion (let’s face it, most discussion on a given RFC happens during voting), and importantly, see how much support the RFC has in order motivate myself to finish the implementation. I think this would be a useful feature for PHP. It brings PHP into line with other modern dynamic languages in having integers of arbitrary size. It makes integer behaviour both more intuitive and more consistent across platforms. It (finally) adds a means for handling of 64-bit (and larger) integers in 32-bit environments. I think allowing integers to grow as needed and not having to worry about platform-specific details is very “PHP”, as well. So, anyway, here’s the RFC, including the voting widget: https://wiki.php.net/rfc/bigint Voting starts today (2015-02-15) and ends in 10 days (2015-02-25). If you have any queries, please ask. Thanks! I think this adds a ton of unnecessary complexity and isn't worth the breaks or performance degradations that come with it. We already have big integer support in the form of the GMP extension, and it is very clear when you are working with arbitrary length integers. But instead this patch adds GMP as a dependency and hides it away internally (or for a bigger performance hit, LibTomMath). Extensions that deal with numbers are all going to need updating. So probably every extension? You talk about eventually deprecating ext/gmp and moving it to PECL. Definitely not acceptable. Sorry, the fixed size integer data type is far too baked-in and useful. I don't see any gain from this patch except hidden performance penalties, breaks, and extra work for everyone in maintaining it and other extensions. I'd rather big int usage was kept verbose and conscious. -1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
Hi, On 15 Feb 2015, at 12:39, Xinchen Hui larue...@php.net wrote: On Sun, Feb 15, 2015 at 10:46 AM, Andrea Faulds a...@ajf.me wrote: Hi everyone, I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker. for such a big change, the implementation self is also important, there was some RFC accepted with not good implementation, which cause lots of troubles for us to maintaining . This vote isn’t to be thought of as accepting the implementation, merely the feature. If the implementation isn’t good enough, the feature could actually be dropped for PHP 7, as much as I hope that won’t happen. Putting it to a vote, finally, means I can stimulate further discussion (let’s face it, most discussion on a given RFC happens during voting), and importantly, see how much support the RFC has in order motivate myself to finish the implementation. I think this would be a useful feature for PHP. It brings PHP into line with other modern dynamic languages in having integers of arbitrary size. It makes integer behaviour both more intuitive and more consistent across platforms. It (finally) adds a means for handling of 64-bit (and larger) integers in 32-bit environments. I think allowing integers to grow as needed and not having to worry about platform-specific details is very “PHP”, as well. from your RFC: but obviously the implementations of anything dealing with integers may need to be changed. this sounds too much compare to the benefits it brings.. (User can use bcmath or other similar thing to deal with big int). It’s not a massive change. All the places in core have already been changed. Most extensions taking integers do so via zpp’s “l” type (or FAST_ZPP’s Z_PARAM_LONG), which handles bigints properly. The main issue is functions accepting zvals (“z” or Z_PARAM_ZVAL). In such cases, the change is usually two lines of code to add an IS_BIGINT case to a switch. and actually, I'd prefer this to be a extension instead of get it into core.. too much changes for little gains.. Thus, I voted -1 on this. Alright, I can understand your perspective. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()
De : Matteo Beccati [mailto:p...@beccati.com] The new methods are: * ReflectionFunctionAbstract::hasReturnTypeAnnotation() * ReflectionFunctionAbstract::getReturnTypeAnnotation() * ReflectionTypeAnnotation::isInstance() I agree Reflection must support hinting but annotations, int the PHP world, are a different concept and don't have anything to do here. OK for ReflectionTypeHint, but not for ReflectionTypeAnnotation. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
Hey: On Sun, Feb 15, 2015 at 10:46 AM, Andrea Faulds a...@ajf.me wrote: Hi everyone, I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker. for such a big change, the implementation self is also important, there was some RFC accepted with not good implementation, which cause lots of troubles for us to maintaining . Putting it to a vote, finally, means I can stimulate further discussion (let’s face it, most discussion on a given RFC happens during voting), and importantly, see how much support the RFC has in order motivate myself to finish the implementation. I think this would be a useful feature for PHP. It brings PHP into line with other modern dynamic languages in having integers of arbitrary size. It makes integer behaviour both more intuitive and more consistent across platforms. It (finally) adds a means for handling of 64-bit (and larger) integers in 32-bit environments. I think allowing integers to grow as needed and not having to worry about platform-specific details is very “PHP”, as well. from your RFC: but obviously the implementations of anything dealing with integers may need to be changed. this sounds too much compare to the benefits it brings.. (User can use bcmath or other similar thing to deal with big int). and actually, I'd prefer this to be a extension instead of get it into core.. too much changes for little gains.. Thus, I voted -1 on this. thanks So, anyway, here’s the RFC, including the voting widget: https://wiki.php.net/rfc/bigint Voting starts today (2015-02-15) and ends in 10 days (2015-02-25). If you have any queries, please ask. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
Hi, On 15 Feb 2015, at 13:07, Leigh lei...@gmail.com wrote: I think this adds a ton of unnecessary complexity and isn't worth the breaks or performance degradations that come with it. We already have big integer support in the form of the GMP extension, and it is very clear when you are working with arbitrary length integers. But instead this patch adds GMP as a dependency and hides it away internally (or for a bigger performance hit, LibTomMath). Extensions that deal with numbers are all going to need updating. So probably every extension? Anything accepting a zval rather than a long through zpp, but the changes are quite small in most cases. It’s a much smaller change than, say, what phpng did. You talk about eventually deprecating ext/gmp and moving it to PECL. Definitely not acceptable. I *talk* about it. I’m not saying we’ll do it. It’s a future possibility: since it would be made largely redundant by large integer support in core, we might eventually get rid of it. I said “might” because it’s not part of the proposal, it is merely a thought. Sorry, the fixed size integer data type is far too baked-in and useful. I could understand your perspective if PHP had modular arithmetic like C and such, but it doesn’t. So I don’t understand why it is “far too useful” - what usefulness is being lost by extending its range? I don't see any gain from this patch except hidden performance penalties, breaks, and extra work for everyone in maintaining it and other extensions. I'd rather big int usage was kept verbose and conscious. I see a clear gain: we clean up almost every integer overflow edge case, integer overflow handling is more intuitive, we support large integers safely on 32-bit, and we don’t require you to use a weird extension that may crash the PHP interpreter and DoS your web host in order to do large number arithmetic. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Design by Contract
Hi Yasuo, Now I understand what you are discussing. Since we may have stricter typing, we probably better to consider type safety theory even if PHP is weakly typed. I am not sure it was about types, it was about conditions... Pre/Postconditions should be checked only when parent method is called. That's what Eiffel does. Eiffel does not allow method overriding. Therefore, pre/postconditions of methods (not invariants. Invariants inherited implicitly(automatically) both Eiffel and D are evaluated except certain methods) cannot be evaluated automatically unless parent method is called. I agree for pre-conditions, but not sure for post-conditions. Since children's method may have whole different way of handing parameters, including swapping parameter order, adding/removing parameters, etc. Parameters cannot be checked automatically unless we have some kind of binding system that bind child parameter to parent parameter. Even if we have it, parameter for parents may be generated in function body. It cannot be perfect. I hadn't thought about this. Parent and derived methods can have different signatures. So, you mean we cannot inherit pre/post-conditions in any way. But what about interfaces, as the signature matches there ? The interface case is complex, as a class can implement more than one interface and interfaces can be extended, providing the same potential problems as multiple inheritance. The parent's post-conditions should be checked too, but in the parent scope, which is probably impossible (using parent argument names). To solve this, we can split post-conditions to two sets : those which deal with the return type and value only, and those that check other conditions (passed by ref args, for instance). Then, the parent's post-conditions which deal with return value only can be checked when the derived methods exit. Basic rule is we shouldn't be able to modify parent contracts(invariant, methods pre/postconditions). If we can change it, it's the same as changing type. Your discussion applies to invariant and this is what you write, I suppose. I am not sure I understand what you mean with 'modify parent contract'. If you mean that we must apply total inheritance for invariants, I agree. The same rule for class applies to interfaces. ?? I don't understand. We cannot ignore parent class invariants. If developer violate parent property restrictions, it's violation of parent class type and this must be forbidden. It's checked by invariant contract. I agree. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
On Sun, Feb 15, 2015 at 8:40 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/15/2015 05:45 AM, Andrea Faulds wrote: Hi, On 15 Feb 2015, at 12:39, Xinchen Hui larue...@php.net wrote: On Sun, Feb 15, 2015 at 10:46 AM, Andrea Faulds a...@ajf.me wrote: Hi everyone, I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker. for such a big change, the implementation self is also important, there was some RFC accepted with not good implementation, which cause lots of troubles for us to maintaining . This vote isn’t to be thought of as accepting the implementation, merely the feature. If the implementation isn’t good enough, the feature could actually be dropped for PHP 7, as much as I hope that won’t happen. At 4 weeks before the feature freeze, we pretty much have to vote for the implementation as well. Every feature that requires significant work puts more pressure on a small group of developers and takes their time away from working on stabilizing the existing code base. No we do not. Many things are not yet stable or will change until 1st beta (or after). It is not realistic nor fair to ask for perfect implementation for such thing. And the time argument is really just an excuse, we got the same issue with the 64bit patch, asking for a perfect patch while php7 did not event exist at this point. It only tells me we need a two phases RFCs for proposals like that. Or proposers simply waste their time because of such votes. My no vote is based on looking at the implementation, the size of the patch and the destabilizing changes to the extension API weighed against its benefits. Too bad. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
On Sun, Feb 15, 2015 at 6:42 PM, Leigh lei...@gmail.com wrote: On 15 February 2015 at 13:51, Andrea Faulds a...@ajf.me wrote: Extensions that deal with numbers are all going to need updating. So probably every extension? Anything accepting a zval rather than a long through zpp, but the changes are quite small in most cases. It’s a much smaller change than, say, what phpng did. The real-world performance gains of ng are significant. Everything is a trade-off. Having to change exts because the guys behind ng have made (potentially) 80% of all websites faster is acceptable - in my opinion. Let be serious here, the zpp changes be for 7 (pls stop calling that ng, it is 7 now :) or for this RFC is irrelevant. An ext wants to support bigint? fine. It can't? Then it will fail or cast with warning or notice. You talk about eventually deprecating ext/gmp and moving it to PECL. Definitely not acceptable. I *talk* about it. I’m not saying we’ll do it. It’s a future possibility: since it would be made largely redundant by large integer support in core, we might eventually get rid of it. I said “might” because it’s not part of the proposal, it is merely a thought. The GMP ext offers a lot more than arbitrary precision arithmetic. There's a slew of functions there that go hand in hand with big ints and their applications. gmp_inverse, gmp_powm and gmp_rootrem to name a few. There are applications, both proprietary and open that depend on these. I'd personally be willing to help bring more functionality to ext/gmp rather than lose all of these important functions to PECL. Fully agree, gmp allows more. And it should not be removed. While native bigint support is really handy and I can see many benefits. Using GMP for other features remain important. Sorry, the fixed size integer data type is far too baked-in and useful. I could understand your perspective if PHP had modular arithmetic like C and such, but it doesn’t. So I don’t understand why it is “far too useful” - what usefulness is being lost by extending its range? Among other thing the behaviour of overflow and shift operations are well documented and understood quirks of fixed size integer types. Does that mean it should not be improved? Aka more obvious and less quirky? I don't see any gain from this patch except hidden performance penalties, breaks, and extra work for everyone in maintaining it and other extensions. I'd rather big int usage was kept verbose and conscious. I see a clear gain: we clean up almost every integer overflow edge case, integer overflow handling is more intuitive, we support large integers safely on 32-bit, and we don’t require you to use a weird extension that may crash the PHP interpreter and DoS your web host in order to do large number arithmetic. A weird extension? The base library of which you are using to back your big int implementation. I agree here too. gmp is just fine. I see this RFC as a different thing. Having bigint support in the engine makes sense regardless of gmp. Other languages have it and are very happy with that. It is simply way easier and cleaner to use than relying on an ext (while Nikita's patch for operators overloading for exts makes things better). Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
On 15 February 2015 at 13:51, Andrea Faulds a...@ajf.me wrote: Extensions that deal with numbers are all going to need updating. So probably every extension? Anything accepting a zval rather than a long through zpp, but the changes are quite small in most cases. It’s a much smaller change than, say, what phpng did. The real-world performance gains of ng are significant. Everything is a trade-off. Having to change exts because the guys behind ng have made (potentially) 80% of all websites faster is acceptable - in my opinion. You talk about eventually deprecating ext/gmp and moving it to PECL. Definitely not acceptable. I *talk* about it. I’m not saying we’ll do it. It’s a future possibility: since it would be made largely redundant by large integer support in core, we might eventually get rid of it. I said “might” because it’s not part of the proposal, it is merely a thought. The GMP ext offers a lot more than arbitrary precision arithmetic. There's a slew of functions there that go hand in hand with big ints and their applications. gmp_inverse, gmp_powm and gmp_rootrem to name a few. There are applications, both proprietary and open that depend on these. I'd personally be willing to help bring more functionality to ext/gmp rather than lose all of these important functions to PECL. Sorry, the fixed size integer data type is far too baked-in and useful. I could understand your perspective if PHP had modular arithmetic like C and such, but it doesn’t. So I don’t understand why it is “far too useful” - what usefulness is being lost by extending its range? Among other thing the behaviour of overflow and shift operations are well documented and understood quirks of fixed size integer types. I don't see any gain from this patch except hidden performance penalties, breaks, and extra work for everyone in maintaining it and other extensions. I'd rather big int usage was kept verbose and conscious. I see a clear gain: we clean up almost every integer overflow edge case, integer overflow handling is more intuitive, we support large integers safely on 32-bit, and we don’t require you to use a weird extension that may crash the PHP interpreter and DoS your web host in order to do large number arithmetic. A weird extension? The base library of which you are using to back your big int implementation. DoS against libgmp is really stretching it here. Yes you can cause all kinds of horrible crashes if you try and do something ridiculous, but that's why you have a programming language that gives you everything you need to sanitise inputs to prevent it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [PRE-VOTE] Remove the date.timezone warning
I'm probably going to put this into vote tomorrow. The RFC got some update from neutrality aspect and covers some feedback from the initial discussion thread. The link is: https://wiki.php.net/rfc/date.timezone_warning_removal https://wiki.php.net/rfc/date.timezone_warning_removal Bob
Re: [PHP-DEV] [VOTE] Big Integer Support
On 02/15/2015 05:45 AM, Andrea Faulds wrote: Hi, On 15 Feb 2015, at 12:39, Xinchen Hui larue...@php.net wrote: On Sun, Feb 15, 2015 at 10:46 AM, Andrea Faulds a...@ajf.me wrote: Hi everyone, I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker. for such a big change, the implementation self is also important, there was some RFC accepted with not good implementation, which cause lots of troubles for us to maintaining . This vote isn’t to be thought of as accepting the implementation, merely the feature. If the implementation isn’t good enough, the feature could actually be dropped for PHP 7, as much as I hope that won’t happen. At 4 weeks before the feature freeze, we pretty much have to vote for the implementation as well. Every feature that requires significant work puts more pressure on a small group of developers and takes their time away from working on stabilizing the existing code base. My no vote is based on looking at the implementation, the size of the patch and the destabilizing changes to the extension API weighed against its benefits. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Remove $this from incompatible context
On 14 February 2015 20:03:44 GMT, Marc Bennewitz dev@mabe.berlin wrote: Hi Am 13.02.2015 um 08:48 schrieb Stanislav Malyshev: Hi! there should be no bc break as the API doesn't change and the method produces the exact same result as before. Sorry, this makes no sense to me. You claim that if you changed the method code to do different thing it should continue working as if you didn't change it? Why? I just don't get it. It's not a good thing to magically change the method API in base of a method body that's not port of the API. magically change the method API? What are you talking about? You changed the code, not magic. Sorry it wasn't clear. I hope I will now: The static modifier for methods is part of the method signature and method body isn't. (That's way interfaces doesn't describe method bodies but signatures) The static modifier defines a method as static and therefore defines the method is callable using ::. More specifically, it defines that the method is *only* callable statically. There is currently no opposite keyword to say that a method can only be called non-statically, but the absence of a modifier has up until now meant that either call type is possible. An interface cannot currently forbid static calls, only the use of $this. Our choice is between keeping that ambiguity, and introducing a new rule that any method not marked static must never be called statically (with provisos for technically non-static parent:: etc). Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Void Return Type
Hi, De : Andrea Faulds [mailto:a...@ajf.me] following codes still works: $b = a(); so, if you want a void return type, and if you want it to be a useful feature.. above expr should be invalid with an error a() return nothing I'm not sure about this. PHP has always made functions valid rvalues, for better or for worse. This RFC could make void functions truly void What about renaming this hint to 'null', instead of 'void'. I know that it supports no explicit return and 'return;' with no value but what it does is more checking that return value is null, than checking return value is 'void', whose concept is not defined yet. It would remove the ambiguity on the fact that the return value is used or not. The only justification is that, in PHP, not returning an explicit value, or using 'return;' returns null, that's history, period. I think it would make the concept easier to understand and would reserve the ambiguous 'void' keyword for the future, if it finds a utility one day. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
Hi Andrea, Thank you for all your hard word and time you've put into this project and it saddens me to see you decide that, but I do understand where you come from. Looking forward for your next project and I wish it will bring you more recognition than this one did. Best regards, Stelian On Mon, Feb 16, 2015 at 12:23 AM, François Laupretre franc...@php.net wrote: De : Andrea Faulds [mailto:a...@ajf.me] So, thank you, PHP community. It has been a wonderful 2 years. That's very sad, but I understand it had gone too far. You're more important than any software project, take care of yourself. Unfortunately, the 'toxic kindergarden' claimed another victim. Not the first one, probably not the last one. And nobody says that's enough. Nobody says it cannot continue this way, losing the best ones. No reaction. No leadership. No education. No balls. It really gets me tired and angry. Who's next ? Good luck, Andrea. Hope to welcome you back soon. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
I am not the core developer of PHP, but I am keeping watch the develop list for long times. Andrea Faulds, actively contributes the PHP core. but it's hard to implement your dream here. So sad I feel. Say no is easier, but do things is hard. the dissenting voices makes things harder and harder. Please do not just say no, no no. Please gave you advice. If you think not right. Please gave us a guide, a tips, a better solution. You just say no, and onto the contribute from who kind heart to help the community. Just uses less. You will push everyone out of the game. Andrea Faulds is one of the very good coder , even she is a beauty girl. Push her out now completely Now you guys feel better, the world got peace? I feel very sad, because the PHP lost a good contributor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sun, Feb 15, 2015 at 7:43 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Anthony, If you are working on JIT, you should understand that declare() switch to strict typing can't improve anything, because it works on caller side and in each function you now will have to generate code for both weak and strict checks. Why do these checks have to be generated in the function, instead of performing checks/casts at the call-site? Naively I would assume this to perform better, because you can make use of type-information around the call-site to elide checks/casts. Or does this have adverse effects due to larger code size or something like that? Nikita
[PHP-DEV] A modest proposal: __contructStatic
Hello Internals, seeing the static calling of instance methods being discussed again, I want to ask whether the following idea would maybe have a chance? In our codebase we have one set of classes where it was very useful to be able to call the same methods both statically and nonstatically: a set of wrapper classes over phpredis where subclasses know which set of redis servers to talk to (plus other config like retry strategies and timeouts). In most cases calling code does not need to be concerned with these details and just calls methods like red_global::get() or red_local::put(). By neccessity the implementation of this class set, must make use of both __call() and __callStatic() magic methods, with both then dispatching to a delegate phpredis instance, and in the case of __callStatic(), making up-front a singleton like new self once. For a set of additional helper methods (not present on the underlying phpredis) I additionally have a special mapping array of real method names to internal implementation names. A similar approach can be useful for database connection abstraction classes. Now for the idea how this might be made much more simple: onviously in the light of the static call to method using $this warning/detection, PHP already knows exactly where it hits such a static call to an instance method. At that point, check whether the class has a static instance already. When it has one, call the method with $this being that static instance. Otherwise, create the static instance, calling a new magick method named __constructStatic() to initialize it. Only classes that have such a __constructStatic() method, would be treated that way. For other classes the static call to instance method case would be an error as before/discussed. This approach would clearly simplify my redis wrapper classes, maybe even enable them to be proper subclasses of phpredis (saving an indirection to a $this-delegate object). All the special dispatch and __callStatic instantiation logic could go away. The cost would be one internal pointer (to the static instance object) per class, a kind of hidden static protected property, and only needed when the class (or one of its superclasses) _has_ a __constructStatic method in the first place. What do you all think? Interesting? Somebody hot for helping with impementation? Then I'd make an RFC of it. best regards Patrick
Re: [PHP-DEV] [RFC] [PRE-VOTE] Remove the date.timezone warning
On 15/02/2015 19:02, Bob Weinand wrote: I'm probably going to put this into vote tomorrow. The RFC got some update from neutrality aspect and covers some feedback from the initial discussion thread. The link is: https://wiki.php.net/rfc/date.timezone_warning_removal https://wiki.php.net/rfc/date.timezone_warning_removal Are you sure that the ini file is created by the package maintainer and it includes the “date.timezone” setting is true? Last time I checked it wasn't true across the board, so it's sounds more like wishful thinking at the moment. But I could be wrong, indeed. The current behaviour is also not described properly. The warning is displayed the first time some date/time functionality is employed. And while I'd agree that generally speaking date.timezone is not the most important setting, in that very moment it most likely is. Your particular problem could be easily fixed by using a common --with-prefix=/opt/php-build and putting the timezone in /opt/php-build/lib/php.ini, so I don't understand the urgency to change the behaviour for everyone... Anyway, let the voting begin ;) Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [PRE-VOTE] Remove the date.timezone warning
On 02/15/2015 08:28 PM, Matteo Beccati wrote: On 15/02/2015 19:02, Bob Weinand wrote: I'm probably going to put this into vote tomorrow. The RFC got some update from neutrality aspect and covers some feedback from the initial discussion thread. The link is: https://wiki.php.net/rfc/date.timezone_warning_removal https://wiki.php.net/rfc/date.timezone_warning_removal Are you sure that the ini file is created by the package maintainer and it includes the “date.timezone” setting is true? Last time I checked it wasn't true across the board, so it's sounds more like wishful thinking at the moment. But I could be wrong, indeed. Gentoo uses one of the php.ini files from the tarball without any modifications. -- Ole Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A modest proposal: __contructStatic
Am 15.02.2015 21:05 schrieb Rowan Collins rowan.coll...@gmail.com: This sounds to me like you should just be using the Singleton pattern, Of course this is singleton under the hood. // Now wherever in the code you want the default instance, just use this: $value = MyRedis::singleton()-get($key); You can surely see how this is more readable / easier to write: $value = MyRedir::get($key); The nice thing about an explicit Singleton is you can migrate to Dependency Injection (call $redis = MyRedis::singleton() and start passing the instance around, I _can_ do that with my redis class, where I need it, by calling a method MyRedis::link() which just returns $this. But the places where I need that are rare. ... or to a cleverer factory / service locator (store more than one instance in different static variables or a keyed array, to connect to different stores for different purposes). This i do with subclasses, where the subclass define suitable static protected properties that guide the connect logic (which sits in the baseclass). I have a global redis, a local redis (local to the host the code runs on), a volatile redis (global, but does not make prersistent dumps), and so on. Calling code ready red_global::this(), red_volatile::that(), and so on. You don't get it better readable (and greppable) as that. Making static calls implicitly access a singleton seems like it would make code harder to read, and harder to extend, I don't understand. It's the best to read to me. And the best to extend - I just make another subclass. Of course, there are places (in other classes) where stuff needs to use such a redis instance without caring which one it is - i.e. an instances is passed to a constructor there - in which case I can use the MyRedis::link() method to get at the singleton instance. But in most (I'd guess 90%) of the calling places, it's just the static calls I need, and writing each of them as MyRedis::singleton()-xxx() is more tedious. best regards Patrick
Re: [PHP-DEV] A modest proposal: __contructStatic
2015-02-15 21:04 GMT+02:00 Patrick Schaaf p...@bof.de: Hello Internals, seeing the static calling of instance methods being discussed again, I want to ask whether the following idea would maybe have a chance? In our codebase we have one set of classes where it was very useful to be able to call the same methods both statically and nonstatically: a set of wrapper classes over phpredis where subclasses know which set of redis servers to talk to (plus other config like retry strategies and timeouts). In most cases calling code does not need to be concerned with these details and just calls methods like red_global::get() or red_local::put(). By neccessity the implementation of this class set, must make use of both __call() and __callStatic() magic methods, with both then dispatching to a delegate phpredis instance, and in the case of __callStatic(), making up-front a singleton like new self once. For a set of additional helper methods (not present on the underlying phpredis) I additionally have a special mapping array of real method names to internal implementation names. A similar approach can be useful for database connection abstraction classes. Now for the idea how this might be made much more simple: onviously in the light of the static call to method using $this warning/detection, PHP already knows exactly where it hits such a static call to an instance method. At that point, check whether the class has a static instance already. When it has one, call the method with $this being that static instance. Otherwise, create the static instance, calling a new magick method named __constructStatic() to initialize it. Only classes that have such a __constructStatic() method, would be treated that way. For other classes the static call to instance method case would be an error as before/discussed. This approach would clearly simplify my redis wrapper classes, maybe even enable them to be proper subclasses of phpredis (saving an indirection to a $this-delegate object). All the special dispatch and __callStatic instantiation logic could go away. The cost would be one internal pointer (to the static instance object) per class, a kind of hidden static protected property, and only needed when the class (or one of its superclasses) _has_ a __constructStatic method in the first place. What do you all think? Interesting? Somebody hot for helping with impementation? Then I'd make an RFC of it. best regards Patrick +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A modest proposal: __contructStatic
On 15/02/2015 19:04, Patrick Schaaf wrote:
In our codebase we have one set of classes where it was very useful to be
able to call the same methods both statically and nonstatically: a set of
wrapper classes over phpredis where subclasses know which set of redis
servers to talk to (plus other config like retry strategies and timeouts).
In most cases calling code does not need to be concerned with these details
and just calls methods like red_global::get() or red_local::put().
By neccessity the implementation of this class set, must make use of both
__call() and __callStatic() magic methods, with both then dispatching to a
delegate phpredis instance, and in the case of __callStatic(), making
up-front a singleton like new self once. For a set of additional helper
methods (not present on the underlying phpredis) I additionally have a
special mapping array of real method names to internal implementation names.
This sounds to me like you should just be using the Singleton pattern,
at which point you need no magic calls at all. It can even be done as a
subclass of an existing non-static class:
class MyRedis extends Redis {
private static $singleton;
public static function singleton() {
if ( is_null(self::$singleton) ) {
self::$singleton = new self; // may need parameters here
}
return self::$singleton;
}
// Other methods can go here, just like a normal subclass
}
// Now wherever in the code you want the default instance, just use this:
$value = MyRedis::singleton()-get($key);
MyRedis::singleton()-someCustomAction($anotherKey);
The nice thing about an explicit Singleton is you can migrate to
Dependency Injection (call $redis = MyRedis::singleton() and start
passing the instance around, until you get to the point where it is only
called once), or to a cleverer factory / service locator (store more
than one instance in different static variables or a keyed array, to
connect to different stores for different purposes).
Making static calls implicitly access a singleton seems like it would
make code harder to read, and harder to extend, in exchange for typing a
few characters on each call (you could call it something shorter, like
::inst() if you valued brevity) so a -1 from me.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: A modest proposal: __contructStatic
Hi Patrick, I don't think it should be implemented. If you are calling a static method like a non-static method, your code has a problem. I think it would do more harm than good. Not only for the code comprehension and logic, but also for the skills of the people who make this mistake. But I find this __constructStatic() method kinda appealing. I'm writing my code so I don't need one, but I may use it if it is implemented. Regards, Benoit. Patrick Schaaf a écrit dans le message de groupe de discussion : Hello Internals, seeing the static calling of instance methods being discussed again, I want to ask whether the following idea would maybe have a chance? In our codebase we have one set of classes where it was very useful to be able to call the same methods both statically and nonstatically: a set of wrapper classes over phpredis where subclasses know which set of redis servers to talk to (plus other config like retry strategies and timeouts). In most cases calling code does not need to be concerned with these details and just calls methods like red_global::get() or red_local::put(). By neccessity the implementation of this class set, must make use of both __call() and __callStatic() magic methods, with both then dispatching to a delegate phpredis instance, and in the case of __callStatic(), making up-front a singleton like new self once. For a set of additional helper methods (not present on the underlying phpredis) I additionally have a special mapping array of real method names to internal implementation names. A similar approach can be useful for database connection abstraction classes. Now for the idea how this might be made much more simple: onviously in the light of the static call to method using $this warning/detection, PHP already knows exactly where it hits such a static call to an instance method. At that point, check whether the class has a static instance already. When it has one, call the method with $this being that static instance. Otherwise, create the static instance, calling a new magick method named __constructStatic() to initialize it. Only classes that have such a __constructStatic() method, would be treated that way. For other classes the static call to instance method case would be an error as before/discussed. This approach would clearly simplify my redis wrapper classes, maybe even enable them to be proper subclasses of phpredis (saving an indirection to a $this-delegate object). All the special dispatch and __callStatic instantiation logic could go away. The cost would be one internal pointer (to the static instance object) per class, a kind of hidden static protected property, and only needed when the class (or one of its superclasses) _has_ a __constructStatic method in the first place. What do you all think? Interesting? Somebody hot for helping with impementation? Then I'd make an RFC of it. best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
- Consider introduction of static require() as class invariant for static
methods
invariant contacts are executed in object methods. I meant adding static
invariant to be executed on static methods.
but I think we don't need them at this point.
I probably don't understand the idea correctly. Could you give some
explanations?
- Need to discuss syntax
There were many ideas for possible syntaxes, I prefer current simple
syntax.
Syntax is not my priority. I don't mind require{assert();},
return{assert();}, etc.
Since error message can be added and any expression is allowed, writing
contracts
as code may be better. We are better to avoid new keyword whenever it's
possible.
- How to manage votes for 2 RFCs
Both RFCs are large enough. How about make vote only RFC
https://wiki.php.net/rfc/dbc_vote
- Explain what is DbC.
- Choose Introduce Native DbC for PHP - Yes or No
- For people voted for Yes, Annotation or Code refer
links to https://wiki.php.net/rfc/dbc, https://wiki.php.net/rfc/dbc2
- Choose Annotation or Code
Sounds good. Alexander should provide one more proposal based on
annotations or attributes.
==Annotation DbC Implementation==
Dmitry, I guess it wouldn't be too hard for you to implement this RFC. How
about annotation
version? Can it be implemented with reasonable amount of efforts?
any implementation of DbC is going to be not trivial...
Thanks. Dmitry.
Thank you all those who are contributed discussion!
I hope you choose to have DbC support. DbC helps to achieve
strict/precise development
and maximum performance in production at the same time.
Regards,
P.S. It takes time to get used to new syntax. We may be better try to
expose new syntax
as much as possible. i.e. Put new syntax in mails whenever possible.
Native DbC support syntax:
class Child {
require($this-age 18); // Invariant (Class state condition)
public function someMethod($input)
require(somethingAbout($input)) // Precondition
return($ret, somethingReturn($ret)) // Postcondition
{
/* Great! We are certain that caller satisfy precondition, return
appropriate return value and have proper class state! */
}
}
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] new json, push generated file?
On Wed, Feb 11, 2015 at 11:56 AM, Jakub Zelenka bu...@php.net wrote: I would like to push the the bison tab files shortly as the majority of people in this thread (including me) are for having them in the repo. The only thing that I would like is to have a specific version in the repo to prevent big diffs for small changes in the source files. For now I would like to have there re2c 0.13.6 (thanks for regenerating it back ;) ) and bison 2.7.1 gen files. I will update Readme at some point as well and add there that info. Hey just a quick update. I bumped the version in the repo for re2c 0.13.7.5 (latest - no changes in generated states ) and bison to 3.0.4 . I updated Readme as well. I have pushed the bison files in http://git.php.net/?p=php-src.git;a=commit;h=911f7b10b1f4c9529bc01580d298a93a5cd6bbd2 . There is an explanation why the C preprocessor guard macro names are file system dependent. It means why there is YY_PHP_JSON_YY_HOME_JAKUB_PROG_PHP_MASTER_EXT_JSON_JSON_PARSER_TAB_H_INCLUDED . It's due to bison algorithm for creating such name. As I noted the only solution that works for me is using different yacc.c skeleton. I have done it in jsond in https://github.com/bukka/php-jsond/commit/583619d7962fa57bf97dcdac4147d8b599a42672 where I have optional bison generation which means that I can stick with one bison version and use custom skeleton file. This is however not possible in the core where we allow range of bison versions which doesn't play well with skeletons that are version specific. When I committed the changes, something went wrong with pushing to github. I hope that my commit hasn't screwed anything up. There is some permission problem probably: Total 5 (delta 3), reused 0 (delta 0) remote: Welcome bukka. remote: Changesets accepted. Thank you for your contribution. remote: remote: Attempting to push to mirror g...@github.com:php/php-src.git remote: Permission denied (publickey). remote: fatal: Could not read from remote repository. remote: remote: Please make sure you have the correct access rights remote: and the repository exists. To g...@git.php.net:php-src.git 549c6fa..5f82c92 master - master Cheers Jakub
RE: [PHP-DEV] Design by Contract
De : Robert Stoll [mailto:p...@tutteli.ch] The theory is actually quite simple. Roughly it says that if you use a type hint of a certain class then you can rely on all pre/post-conditions of this class even if a sub-class is passed. Hence the sub-class cannot have more restrict conditions. I guess from the example above it should be clear why D has implemented it this way OK. Thanks for your explanations. What I meant is that, while I understand the theory, I don't understand the reason *why* it must be done this way. An additional point is that, IMO, It is impossible for a software to enforce the theory and check that a set of conditions is more or less restrictive than another one, except analyzing them, which is far beyond our possibilities. So, IMO, we can just give it as a convention, which is quite poor. That's why I preferred to use another logic. But I would like to know if it won't bring other problems later. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Combined Comparison (Spaceship) Operator
Le 02/02/2015 13:06, Andrea Faulds a écrit : The RFC, which contains the voting widget, can be found here: https://wiki.php.net/rfc/combined-comparison-operator Thanks! Hi, Discussing this RFC with other people of AFUP, we would be +1. Basically: adding such an operator would make things much easier when it comes to writing comparison functions. (Even though the RFC has been withdrawn, I thought posting this could help, if anyone wishes to keep working on it) -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A modest proposal: __contructStatic
On 15/02/2015 20:20, Patrick Schaaf wrote:
Am 15.02.2015 21:05 schrieb Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com:
This sounds to me like you should just be using the Singleton pattern,
Of course this is singleton under the hood.
// Now wherever in the code you want the default instance, just use this:
$value = MyRedis::singleton()-get($key);
You can surely see how this is more readable / easier to write:
$value = MyRedir::get($key);
Actually, no, I find that harder to read accurately - there is no clue
there that there is actually a singleton under the hood, and that this
is actually an instance method in disguise.
For writing, it saves, in this case, 13 characters; change the method
name to inst(), and that difference goes down to 8 characters.
And if you use it lots of times in succession, you wouldn't even need to
call the accessor every time:
$redis = MyRedis::inst();
$foo = $redis-get('foo');
$bar = $redis-get('bar');
// etc
In that scenario, you've had to write one extra line at the top of the
method, and the rest of the lines are probably shorter (if the variable
name is more than one character shorter than the class name). Plus, you
have the bonus of being able to use an injected connection later.
The nice thing about an explicit Singleton is you can migrate to Dependency Injection (call $redis =
MyRedis::singleton() and start passing the instance around,
I _can_ do that with my redis class, where I need it, by calling a
method MyRedis::link() which just returns $this. But the places where
I need that are rare.
You may be able to do it with your current implementation, but how do
you propose to do it with an invisible singleton property implicitly
created by __constructStatic?
... or to a cleverer factory / service locator (store more than one instance in different static variables or a
keyed array, to connect to different stores for different purposes).
This i do with subclasses, where the subclass define suitable static
protected properties that guide the connect logic (which sits in the
baseclass). I have a global redis, a local redis (local to the host
the code runs on), a volatile redis (global, but does not make
prersistent dumps), and so on. Calling code ready red_global::this(),
red_volatile::that(), and so on. You don't get it better readable (and
greppable) as that.
OK, but you need a new subclass every time, not just a new method, or
new parameter; that limits your options. For instance, you can't
dynamically create instances based on configuration of a reusable
library, which could be as simple as adding an optional parameter to a
standard Singleton:
class MyRedis {
private static $instances;
public static function inst($type='default') {
global $config;
if ( ! array_key_exists(self::$instances, $type) ) {
self::$instances[$type] = new self(...$config['redis_options'][$type]);
}
return self::$instances[$type];
}
}
Any function that already uses the $redis = MyRedis::inst(); pattern
can then quickly be changed to $redis = MyRedis::inst('volatile'); and
continue to work fine.
Making static calls implicitly access a singleton seems like it would make code harder to read, and harder to
extend,
I don't understand. It's the best to read to me.
OK, we'll call that one a matter of opinion.
And the best to extend - I just make another subclass.
Extend was perhaps not the word I should have chosen; I was thinking
of extending the use of the class beyond the current coding pattern.
By implementing one specific use case as a magic method, you make it
harder to do anything other than that one use case; or, you end up
creating a whole set of magic methods and features, which are then no
easier than just implementing the whole thing by hand.
I deliberately didn't go into details of the arguments against the
Singleton pattern in general in my last e-mail, because I was comparing
your magic code to a normal Singleton. However, those criticisms are
out there, and adding a feature to the language specifically in order to
support Singletons, in a very limited way, will be considered by some as
encouraging bad practice.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
Thanks for all you've done for PHP in so short time! You've been representing a big part of the community with your remarkable work. You are quitting internals but will stay as a reference on PHP community. Márcio
Re: [PHP-DEV] I quit.
On 15/02/2015 22:15, Andrea Faulds wrote: It might be for the best that we don’t keep it in voting. During the voting process, it became apparent that the declare() syntax (with all its idiosyncrasies) was a big problem (influencing at least 3 people’s votes), so much so that I decided that I’d make a follow-up RFC to fix it after voting ended, to avoid having to cancel the vote. Now that voting’s cancelled, that could be fixed properly if someone revived the RFC. People voting one way or another, or their reasons for voting, should never be a reason to stop a vote, particularly one that has been going for so long, and received so many votes. That way, madness lies, because someone could keep closing and reopening different versions of a vote, and people whose vote was not influenced by that factor would have to keep remembering to re-register their unchanged vote. If the vote fails, we know that some people may be persuaded to vote differently (in either direction) on a similar proposal with different syntax; if it passes, there is nothing to stop another vote defining a different syntax before 7.0 is released. I think the vote totals still make a statement. The vote may have ended 4 days early, but it’s only 1 vote short of a 2/3 majority. That's why I think it should continue; so that that statement is not open to argument. Right now, anyone who disagrees with the result can simply say well, it was closed early, so it's meaningless. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 14/02/2015 00:09, Yasuo Ohgaki wrote:
Hi Nikita,
On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov nikita@gmail.com wrote:
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.
Are E_WARNING, etc future scope?
I briefly looked the patch. It seems it covers only engine errors.
I suppose it's the scope of this RFC, though.
If API is made adoptable to modules for E_WARNING, etc, it would be
great.
Much though I'd love a more OO-approach to warnings, exceptions are not
an appropriate mechanism for that.
A rule of thumb I rather like is that you should only throw an exception
in a case where your best alternative, if it is not handled, is to call
die(). Clearly, E_ERROR meets this standard, and E_WARNING does not.
There has been much talk previously that exceptions are great because
they include full backtraces, but there's no reason a new type of
warning object couldn't also include those, while retaining the key
characteristic of the default behaviour being to carry on with some
fallback value (an empty loop, a null variable, etc) rather than to
die('Uncaught Warning Exception!').
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A modest proposal: __contructStatic
On 15/02/2015 19:04, Patrick Schaaf wrote:
By neccessity the implementation of this class set, must make use of both
__call() and __callStatic() magic methods, with both then dispatching to a
delegate phpredis instance, and in the case of __callStatic(), making
up-front a singleton like new self once. For a set of additional helper
methods (not present on the underlying phpredis) I additionally have a
special mapping array of real method names to internal implementation names.
A quick thought - if you want to stick with the magic static call
pattern, you can implement this much more simply by doing something
similar to Laravel's facades [1]:
class MyRedis extends Redis {
// extra instance methods here
}
class MyRedisFacade {
private static $instance;
public static function __callStatic($method, $params) {
if ( is_null(self::$instance) ) {
self::$instance = new MyRedis;
}
self::$instance-$method(...$params);
}
}
This basically implements in userspace what you propose to add to the
language, with the only caveat being that you must separate the concerns
of adding extra functionality, and wrapping it in a static facade, into
two separate classes.
[1] http://laravel.com/docs/4.2/facades
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Design by Contract
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki D resolves that if parameter is contract or not at compile time and checks it if method is overriding parent's method. If method is overridden, D just ignores contract. That's true for pre-conditions, but that's not the way D handles post-conditions. The same rule for class applies to interfaces. ?? I don't understand. Interface may have contracts just like class. OK, but when do you check interface conditions ? And how do you deal with interface (multiple) inheritance ? We cannot ignore parent class invariants. If developer violate parent property restrictions, it's violation of parent class type and this must be forbidden. It's checked by invariant contract. I agree. We have(had) weak type system. Choosing right type system for PHP would be very hard. I didn't intended to bring this topic... Could we introduce simple Design by Contract concept? Or are we going to discuss right type system for PHP? Sure, but are you realizing that you're discarding your own statement, not mine ? I never told about the PHP type system because I don't understand what types have to do here. So, yes, I don't care about the PHP type system and that's not the subject. We are discussing about PHP conditions and when they are evaluated, that's all. And, sorry about that, but could you stop sending html messages ? It makes replies much harder. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A modest proposal: __contructStatic
Patrick Schaaf wrote: Am 15.02.2015 21:05 schrieb Rowan Collins rowan.coll...@gmail.com: // Now wherever in the code you want the default instance, just use this: $value = MyRedis::singleton()-get($key); You can surely see how this is more readable / easier to write: $value = MyRedir::get($key); It's possible to add static methods or use __callStatic() to delegate to the singleton's instance methods, though. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I quit.
De : Andrea Faulds [mailto:a...@ajf.me] So, thank you, PHP community. It has been a wonderful 2 years. That's very sad, but I understand it had gone too far. You're more important than any software project, take care of yourself. Unfortunately, the 'toxic kindergarden' claimed another victim. Not the first one, probably not the last one. And nobody says that's enough. Nobody says it cannot continue this way, losing the best ones. No reaction. No leadership. No education. No balls. It really gets me tired and angry. Who's next ? Good luck, Andrea. Hope to welcome you back soon. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi Francois,
On Mon, Feb 16, 2015 at 1:08 AM, François Laupretre franc...@php.net
wrote:
Now I understand what you are discussing. Since we may have stricter
typing, we probably better
to consider type safety theory even if PHP is weakly typed.
I am not sure it was about types, it was about conditions...
Type theory is not too complex, but it's contradictory against common
sense.
I guess it's one of the reason (or main reason) why D folks dropped class
invariant
support even if it's very useful.
Choosing right type system is not simple. Not all languages has the same.
http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
As you can see, languages has different type system.
Argument type Return type
C++ (since 1998), Java (since J2SE 5.0), Scala, D Invariant
Covariant
C#
InvariantInvariant
Sather
Contravariant Covariant
Eiffel
Covariant Covariant
It seems how we should/are going to handle types in detail. (Or we may say
PHP is weakly typed, let's forget about types for DbC for now and stick to
basic DbC concept only.)
Pre/Postconditions should be checked only when parent method is called.
That's what Eiffel does.
Eiffel does not allow method overriding. Therefore, pre/postconditions
of
methods (not invariants.
Invariants inherited implicitly(automatically) both Eiffel and D are
evaluated except certain
methods) cannot be evaluated automatically unless parent method is
called.
I agree for pre-conditions, but not sure for post-conditions.
Since children's method may have whole different way of handing
parameters,
including swapping parameter order, adding/removing parameters, etc.
Parameters cannot be checked automatically unless we have some kind of
binding system that bind child parameter to parent parameter. Even if we
have
it, parameter for parents may be generated in function body. It cannot
be
perfect.
I hadn't thought about this. Parent and derived methods can have
different signatures.
So, you mean we cannot inherit pre/post-conditions in any way.
But what about interfaces, as the signature matches there ? The interface
case is complex, as a class can implement more than one interface and
interfaces can be extended, providing the same potential problems as
multiple inheritance.
The parent's post-conditions should be checked too, but in the parent
scope, which is probably impossible (using parent argument names). To solve
this, we can split post-conditions to two sets : those which deal with the
return type and value only, and those that check other conditions (passed
by ref args, for instance). Then, the parent's post-conditions which deal
with return value only can be checked when the derived methods exit.
D resolves that if parameter is contract or not at compile time and checks
it if method
is overriding parent's method. If method is overridden, D just ignores
contract. In short,
D does complex analysis during compilation.
Work around of this is simple, just call parent method using super. e.g.
/* Not D syntax */
function foo() {
super.foo();
}
If parent method is called, both child and parent contract is evaluated.
(With Eiffel, rename parent method and call it optionally.)
PHP's default could be this way and this is what I thought originally. This
is
simple and expected behavior for most people. PHP is weakly typed, so
it's enough. (I might have to say it was)
Basic rule is we shouldn't be able to modify parent contracts(invariant,
methods pre/postconditions).
If we can change it, it's the same as changing type. Your discussion
applies to invariant and this
is what you write, I suppose.
I am not sure I understand what you mean with 'modify parent contract'.
If you mean that we must apply total inheritance for invariants, I agree.
D disallow modifying parent's method contract when method is overridden
unless child method call super.parentMethod().
Eiffel is even stricter, it disallows overriding parent. It only allows to
remove
or rename parent's method.
The same rule for class applies to interfaces.
?? I don't understand.
Interface may have contracts just like class.
We cannot ignore parent class invariants. If developer violate parent
property restrictions,
it's violation of parent class type and this must be forbidden. It's
checked by invariant contract.
I agree.
We have(had) weak type system. Choosing right type system for PHP would be
very hard.
I didn't intended to bring this topic... Could we introduce simple Design
by Contract
concept? Or are we going to discuss right type system for PHP?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] I quit.
On 2/15/2015 2:21 PM, Andrea Faulds wrote: Hi everyone, For my own reasons, I have decided to cease my involvement with PHP development. This isn’t a judgement of the PHP community nor the internals mailing list, you’re all wonderful people and it’s really been a pleasure, and I mean that completely honestly. However, this has ended up taking up too much of my time (which is my own fault, and my own fault alone) and I can’t really justify it to myself anymore. So, I’m no longer contributing to PHP, and all four active RFCs authored by myself are therefore withdrawn: Scalar Type Hints, Spaceship/Combined Comparison Operator, Void Return Type, Big Integer Support. The first two were in voting, so the votes have been cancelled. If anyone would like to pick up from where I left off with any of these RFCs, they are very much welcome to - there is no need to consult me first (and it’s probably for the best if you don’t). The Spaceship/Combined Comparison Operator RFC was also authored by Davey Shafik, so ask him if you want to revive that one. I’m sorry about this, but it can’t be helped. I’d rather move on to other things. I would stick around to finish everything up before I leave, but I just don’t have the time nor the motivation to finish everything. I apologise for that, especially for Scalar Type Hints as I realise this is something a lot of developers were looking forward to. I’d leave quietly, but since this affects active RFCs, I need to announce it somewhere. So, thank you, PHP community. It has been a wonderful 2 years. Goodbye. -- Andrea Faulds http://ajf.me/ Thank you for being a responsible software developer. Not many developers are this forward and honest about their intentions/plans. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
On 15/02/2015 21:21, Andrea Faulds wrote: Hi everyone, For my own reasons, I have decided to cease my involvement with PHP development. This isn’t a judgement of the PHP community nor the internals mailing list, you’re all wonderful people and it’s really been a pleasure, and I mean that completely honestly. However, this has ended up taking up too much of my time (which is my own fault, and my own fault alone) and I can’t really justify it to myself anymore. So, I’m no longer contributing to PHP, and all four active RFCs authored by myself are therefore withdrawn: Scalar Type Hints, Spaceship/Combined Comparison Operator, Void Return Type, Big Integer Support. The first two were in voting, so the votes have been cancelled. If anyone would like to pick up from where I left off with any of these RFCs, they are very much welcome to - there is no need to consult me first (and it’s probably for the best if you don’t). The Spaceship/Combined Comparison Operator RFC was also authored by Davey Shafik, so ask him if you want to revive that one. I’m sorry about this, but it can’t be helped. I’d rather move on to other things. I would stick around to finish everything up before I leave, but I just don’t have the time nor the motivation to finish everything. I apologise for that, especially for Scalar Type Hints as I realise this is something a lot of developers were looking forward to. I’d leave quietly, but since this affects active RFCs, I need to announce it somewhere. So, thank you, PHP community. It has been a wonderful 2 years. I'm really really sorry to hear this. The energy you've put into the project recently has been really appreciated by many people, and I really admire your dedication to finding compromises to controversial topics. I can see, though, that it takes a lot of time to be that actively involved on a voluntary basis, and that a clean break might feel necessary to shift your focus. I hope to see your name in future, either in a less involved role in PHP, or in some other project. On a purely procedural note, though, is there some way the Scalar Type Hints RFC can be left in voting, as a vote in principle, while we wait for someone to step up and take over the implementation? There are only 4 days left, and with over 100 votes cast, it seems a shame to say that they were all meaningless, while leaving the door open to start all over again. I think it will hurt people's faith in the process to cancel now, and can't think of a particularly strong reason not to let the vote run its course before deciding what to do next. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
Andrea, I'm sure this thread will explode shortly, but all the best in whatever you will do with the newly free time. Paddy On 15 February 2015 at 21:21, Andrea Faulds a...@ajf.me wrote: Hi everyone, For my own reasons, I have decided to cease my involvement with PHP development. This isn’t a judgement of the PHP community nor the internals mailing list, you’re all wonderful people and it’s really been a pleasure, and I mean that completely honestly. However, this has ended up taking up too much of my time (which is my own fault, and my own fault alone) and I can’t really justify it to myself anymore. So, I’m no longer contributing to PHP, and all four active RFCs authored by myself are therefore withdrawn: Scalar Type Hints, Spaceship/Combined Comparison Operator, Void Return Type, Big Integer Support. The first two were in voting, so the votes have been cancelled. If anyone would like to pick up from where I left off with any of these RFCs, they are very much welcome to - there is no need to consult me first (and it’s probably for the best if you don’t). The Spaceship/Combined Comparison Operator RFC was also authored by Davey Shafik, so ask him if you want to revive that one. I’m sorry about this, but it can’t be helped. I’d rather move on to other things. I would stick around to finish everything up before I leave, but I just don’t have the time nor the motivation to finish everything. I apologise for that, especially for Scalar Type Hints as I realise this is something a lot of developers were looking forward to. I’d leave quietly, but since this affects active RFCs, I need to announce it somewhere. So, thank you, PHP community. It has been a wonderful 2 years. Goodbye. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Dmitry, On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Anthony, If you are working on JIT, you should understand that declare() switch to strict typing can't improve anything, because it works on caller side and in each function you now will have to generate code for both weak and strict checks. Well, if you know the destination function at compile time, you don't need to generate generic code. you can generate a direct dispatch (asm-level function call). In this case, strict lets you push type checks back to compile time, where in non-strict mode you still need to generation runtime conversion logic. That runtime conversion logic then requires the ability to hook into Zend's error handling mechanism, vastly complicating the generated code (and the generating code). In fact, the research I have been doing is precisely around that (where I know for a fact that all remaining function calls are going to be typed, and compile the entire block at one time with direct calls). So that way I never need to actually do even as much as a FCC to call a userland function. Which then lets me avoid generating typing code (since I know the types). Which is why I'm advocating for strict, since that way we can treat an entire graph of function calls as strict and compile them all in one go (no need to even JIT at runtime, just compile AOT). If your research has shown something different, care to share? According to mandel() and integer to float conversion in the loop, it's possible to perform a backward data-propagation pass to catch this case and replace integer by float in first place. We did it in our old JIT prototypes without any type hinting. Also, don't use fild, use SSE2 and/or AVX. I did wind up doing a few passes to back-propagate the cast (among other optimizations). But it's still a point that the conversions aren't exactly cheap. But as I said before, that was a side-note and not really an argument for/against strict typing. So worth mentioning, but shouldn't affect anyone's decision. Re fild vs SSE/AVX: that was up to the backend code generator we were using (libjit). It may be an open req against that lib to generate the different instruction, or perhaps it just failed a heuristic. We were working a level higher than the generated ASM, so not really 100% sure why it made that decision. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
On Sun, Feb 15, 2015 at 4:21 PM, Andrea Faulds a...@ajf.me wrote: Hi everyone, For my own reasons, I have decided to cease my involvement with PHP development. This isn’t a judgement of the PHP community nor the internals mailing list, you’re all wonderful people and it’s really been a pleasure, and I mean that completely honestly. However, this has ended up taking up too much of my time (which is my own fault, and my own fault alone) and I can’t really justify it to myself anymore. So, I’m no longer contributing to PHP, and all four active RFCs authored by myself are therefore withdrawn: Scalar Type Hints, Spaceship/Combined Comparison Operator, Void Return Type, Big Integer Support. The first two were in voting, so the votes have been cancelled. If anyone would like to pick up from where I left off with any of these RFCs, they are very much welcome to - there is no need to consult me first (and it’s probably for the best if you don’t). The Spaceship/Combined Comparison Operator RFC was also authored by Davey Shafik, so ask him if you want to revive that one. I’m sorry about this, but it can’t be helped. I’d rather move on to other things. I would stick around to finish everything up before I leave, but I just don’t have the time nor the motivation to finish everything. I apologise for that, especially for Scalar Type Hints as I realise this is something a lot of developers were looking forward to. I’d leave quietly, but since this affects active RFCs, I need to announce it somewhere. So, thank you, PHP community. It has been a wonderful 2 years. Goodbye. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I do not accept this. You are one of the most active, motivated and appreciated contributors of PHP over the last few years. Not to shit on anyone specifically, but there are only 4 or 5 people doing 80% of the work of PHP recently, and you are one of them. Scalar Type Hints are a massive burden, and you're stuck in the middle of everyone who has a strong opinion about either strict or weak and getting screamed at by both camps at the same time as getting crap from the people who dont want either. I constantly see people giving you shit in here, on Reddit, StackOverflow Chat and wherever else and it sickens me. They're condescending, patronising or at the very least missing some P's and Q's which are fairly important when giving feedback as harsh as they often give. The lack of respect between contributors here in general sickens me, and I'm not known as somebody who is wildly polite at all times. Scalar Type Hinting was the closest it's ever been. If the workload is too much then stick to one RFC at a time, but to remove yourself from the equation is a massive loss for PHP as a whole. I'm not trying to place a burden on you, but your input will be sorely missed by a massive number of people. Please, don't let the assholes win. PHP needs you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
Hey Rowan, On 15 Feb 2015, at 22:07, Rowan Collins rowan.coll...@gmail.com wrote: I'm really really sorry to hear this. The energy you've put into the project recently has been really appreciated by many people, and I really admire your dedication to finding compromises to controversial topics. I can see, though, that it takes a lot of time to be that actively involved on a voluntary basis, and that a clean break might feel necessary to shift your focus. I hope to see your name in future, either in a less involved role in PHP, or in some other project. Thank you. On a purely procedural note, though, is there some way the Scalar Type Hints RFC can be left in voting, as a vote in principle, while we wait for someone to step up and take over the implementation? There are only 4 days left, and with over 100 votes cast, it seems a shame to say that they were all meaningless, while leaving the door open to start all over again. I think it will hurt people's faith in the process to cancel now, and can't think of a particularly strong reason not to let the vote run its course before deciding what to do next. It might be for the best that we don’t keep it in voting. During the voting process, it became apparent that the declare() syntax (with all its idiosyncrasies) was a big problem (influencing at least 3 people’s votes), so much so that I decided that I’d make a follow-up RFC to fix it after voting ended, to avoid having to cancel the vote. Now that voting’s cancelled, that could be fixed properly if someone revived the RFC. I think the vote totals still make a statement. The vote may have ended 4 days early, but it’s only 1 vote short of a 2/3 majority. I’m not sure, really. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A modest proposal: __contructStatic
create the static instance Isn't that essentially a contradiction in terms? I can't help but feel that blurring the line between static and non-static classes/methods would cause more harm than good. I've never really done any work with Redis before so I'm also having trouble understanding the use case for this given that everybody's talking about this solely in the context of Redis. --Kris
[PHP-DEV] Spaceship operator RFC
Hi! Since Andrea has withdrawn the spaceship operator RFC (https://wiki.php.net/rfc/combined-comparison-operator), I'd like to resurrect it. Looks like by vote results (with 1 day of official vote left) it was clearly passing, so are there any objections to treating it as passed? If not, I'll treat it as such and do the merging as soon as I have time. Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi Francois, On Mon, Feb 16, 2015 at 8:08 AM, François Laupretre franc...@php.net wrote: De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki D resolves that if parameter is contract or not at compile time and checks it if method is overriding parent's method. If method is overridden, D just ignores contract. That's true for pre-conditions, but that's not the way D handles post-conditions. The same rule for class applies to interfaces. ?? I don't understand. Interface may have contracts just like class. OK, but when do you check interface conditions ? And how do you deal with interface (multiple) inheritance ? Simply check all contracts on method calls. If property check (invariant) could be issue, class designer should use document for proper property management rather than contracts. Or we may drop invariant support for interface. We cannot ignore parent class invariants. If developer violate parent property restrictions, it's violation of parent class type and this must be forbidden. It's checked by invariant contract. I agree. We have(had) weak type system. Choosing right type system for PHP would be very hard. I didn't intended to bring this topic... Could we introduce simple Design by Contract concept? Or are we going to discuss right type system for PHP? Sure, but are you realizing that you're discarding your own statement, not mine ? Type safety consideration was not intended at first. So I don't have problem with disregarding type safety. We may introduce type safety/system when we have template, strict types and/or overloading, for example. I never told about the PHP type system because I don't understand what types have to do here. So, yes, I don't care about the PHP type system and that's not the subject. We are discussing about PHP conditions and when they are evaluated, that's all. And, sorry about that, but could you stop sending html messages ? It makes replies much harder. It seems gmail does not have the option, but I can only remove text formatting manually. Does this mail seems OK to you? Anyway, how about not to consider type safety too much now? and concentrate to introduce simple DbC? We may have option for strict type in the future for whatever type system we introduce at that time. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] I quit.
May be leave for a while can let she happier than before. Do not censure her -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP JIT or AOT
I guess we can gave a try. PHP 7 is fine well enough. let's working hard to make it published. The talk about other things should be early . let's see PHP 7 released and see how it will change our world. Code it , ship it. Let's see the result. Appreciate your time. Netroby 2015-02-16 15:32 GMT+08:00 Dmitry Stogov dmi...@zend.com: On Mon, Feb 16, 2015 at 10:16 AM, Joe Watkins pthre...@pthreads.org wrote: Morning, I'm not sure where this conversation started ... it's a fork from Salar Type Hints... where in non-strict mode you still need to generation runtime conversion logic. That runtime conversion logic then requires the ability to hook into Zend's error handling mechanism, vastly complicating the generated code (and the generating code). Why do you need to generate conversion logic, why can't you call Zend API functions ? Even VM just calls a conversion function. Alternatively, possibly preferably, wouldn't a guard to tell if the function is being called in strict mode be a good idea here ? If we know what function is called in strict mode, we must already know where it's called from, so we should also know the types of passed arguments, then we may eliminate checks at all (independently on strictness). If we don't know the types we will need to check them anyway. If the generated code is really complicated and that sucks away the performance then why not just avoid it, and only enter machine code when a function is called in strict mode ? I see the assembly generated by your JIT, but it doesn't really tell us much, it tells us a little, what would be really useful is seeing your research, with the understanding that it is just research. Please think about that again. Yeah, we will need to open it, even if it doesn't make gain for real life. but lets make all the PHP7 related work first. I would be glad, if later we'll combine our experience and work on JIT/AOT together. Thanks. Dmitry. Cheers Joe On Mon, Feb 16, 2015 at 6:59 AM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Anthony, If you are working on JIT, you should understand that declare() switch to strict typing can't improve anything, because it works on caller side and in each function you now will have to generate code for both weak and strict checks. Well, if you know the destination function at compile time, you don't need to generate generic code. you can generate a direct dispatch (asm-level function call). Right, but in real life app you almost never know what function or method you are really call. At function you also can't be sure that it always called with proper arguments. This work well only for plain function placed into a single PHP file. In this case, strict lets you push type checks back to compile time, where in non-strict mode you still need to generation runtime conversion logic. That runtime conversion logic then requires the ability to hook into Zend's error handling mechanism, vastly complicating the generated code (and the generating code). For cases when you know the called function and all passed and expected types, it's possible to use more efficient calling convention passing real arguments in CPU registers. The type checks in PHP7 is quite cheap (2-3 CPU instructions). Strict or weak check doesn't make any difference for fast path (the same 2-3 instructions). The slow patch for weak checks is going to be a bit more expensive. In fact, the research I have been doing is precisely around that (where I know for a fact that all remaining function calls are going to be typed, and compile the entire block at one time with direct calls). So that way I never need to actually do even as much as a FCC to call a userland function. Which then lets me avoid generating typing code (since I know the types). Which is why I'm advocating for strict, since that way we can treat an entire graph of function calls as strict and compile them all in one go (no need to even JIT at runtime, just compile AOT). If your research has shown something different, care to share? Very similar :), but in cases when we know the called function the effect from type hinting is negligible. It's almost always possible to generate optimal code without any hints. See code for fibo_r() from bench.php generated by our old JIT for PHP-5.5 (without type hinting): https://gist.github.com/dstogov/5f71d23f387332e9d77c Unfortunately, we didn't make the same for PHP7 yet. More important, in our experiments we saw improvements only on small benchmarks (e.g. 25 times on mandelbrot), but nothing on real-life apps. So a some point, looking into ASM code that endlessly allocates and frees zvals, we switched to
Re: [PHP-DEV] [RFC] [PRE-VOTE] Remove the date.timezone warning
Hi! Are you sure that the ini file is created by the package maintainer and it includes the “date.timezone” setting is true? Last time I checked it I my experience, it is unfortunately not universally true - I've seen Linux distros with ini files that don't do that. Setting TZ correctly would require some non-trivial script work, and I'm guessing whoever did the package did not want to do this work. They could of course just put UTC there but that didn't happen either. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP JIT or AOT
Morning, I'm not sure where this conversation started ... where in non-strict mode you still need to generation runtime conversion logic. That runtime conversion logic then requires the ability to hook into Zend's error handling mechanism, vastly complicating the generated code (and the generating code). Why do you need to generate conversion logic, why can't you call Zend API functions ? Alternatively, possibly preferably, wouldn't a guard to tell if the function is being called in strict mode be a good idea here ? If the generated code is really complicated and that sucks away the performance then why not just avoid it, and only enter machine code when a function is called in strict mode ? I see the assembly generated by your JIT, but it doesn't really tell us much, it tells us a little, what would be really useful is seeing your research, with the understanding that it is just research. Please think about that again. Cheers Joe On Mon, Feb 16, 2015 at 6:59 AM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Anthony, If you are working on JIT, you should understand that declare() switch to strict typing can't improve anything, because it works on caller side and in each function you now will have to generate code for both weak and strict checks. Well, if you know the destination function at compile time, you don't need to generate generic code. you can generate a direct dispatch (asm-level function call). Right, but in real life app you almost never know what function or method you are really call. At function you also can't be sure that it always called with proper arguments. This work well only for plain function placed into a single PHP file. In this case, strict lets you push type checks back to compile time, where in non-strict mode you still need to generation runtime conversion logic. That runtime conversion logic then requires the ability to hook into Zend's error handling mechanism, vastly complicating the generated code (and the generating code). For cases when you know the called function and all passed and expected types, it's possible to use more efficient calling convention passing real arguments in CPU registers. The type checks in PHP7 is quite cheap (2-3 CPU instructions). Strict or weak check doesn't make any difference for fast path (the same 2-3 instructions). The slow patch for weak checks is going to be a bit more expensive. In fact, the research I have been doing is precisely around that (where I know for a fact that all remaining function calls are going to be typed, and compile the entire block at one time with direct calls). So that way I never need to actually do even as much as a FCC to call a userland function. Which then lets me avoid generating typing code (since I know the types). Which is why I'm advocating for strict, since that way we can treat an entire graph of function calls as strict and compile them all in one go (no need to even JIT at runtime, just compile AOT). If your research has shown something different, care to share? Very similar :), but in cases when we know the called function the effect from type hinting is negligible. It's almost always possible to generate optimal code without any hints. See code for fibo_r() from bench.php generated by our old JIT for PHP-5.5 (without type hinting): https://gist.github.com/dstogov/5f71d23f387332e9d77c Unfortunately, we didn't make the same for PHP7 yet. More important, in our experiments we saw improvements only on small benchmarks (e.g. 25 times on mandelbrot), but nothing on real-life apps. So a some point, looking into ASM code that endlessly allocates and frees zvals, we switched to engine re-factoring. According to mandel() and integer to float conversion in the loop, it's possible to perform a backward data-propagation pass to catch this case and replace integer by float in first place. We did it in our old JIT prototypes without any type hinting. Also, don't use fild, use SSE2 and/or AVX. I did wind up doing a few passes to back-propagate the cast (among other optimizations). But it's still a point that the conversions aren't exactly cheap. But as I said before, that was a side-note and not really an argument for/against strict typing. So worth mentioning, but shouldn't affect anyone's decision. Re fild vs SSE/AVX: that was up to the backend code generator we were using (libjit). It may be an open req against that lib to generate the different instruction, or perhaps it just failed a heuristic. We were working a level higher than the generated ASM, so not really 100% sure why it made that decision. I saw a big speed difference between FPU and SSE2/AVX code on bench.php, so if you may tell
Re: [PHP-DEV] PHP JIT or AOT
On Mon, Feb 16, 2015 at 10:16 AM, Joe Watkins pthre...@pthreads.org wrote: Morning, I'm not sure where this conversation started ... it's a fork from Salar Type Hints... where in non-strict mode you still need to generation runtime conversion logic. That runtime conversion logic then requires the ability to hook into Zend's error handling mechanism, vastly complicating the generated code (and the generating code). Why do you need to generate conversion logic, why can't you call Zend API functions ? Even VM just calls a conversion function. Alternatively, possibly preferably, wouldn't a guard to tell if the function is being called in strict mode be a good idea here ? If we know what function is called in strict mode, we must already know where it's called from, so we should also know the types of passed arguments, then we may eliminate checks at all (independently on strictness). If we don't know the types we will need to check them anyway. If the generated code is really complicated and that sucks away the performance then why not just avoid it, and only enter machine code when a function is called in strict mode ? I see the assembly generated by your JIT, but it doesn't really tell us much, it tells us a little, what would be really useful is seeing your research, with the understanding that it is just research. Please think about that again. Yeah, we will need to open it, even if it doesn't make gain for real life. but lets make all the PHP7 related work first. I would be glad, if later we'll combine our experience and work on JIT/AOT together. Thanks. Dmitry. Cheers Joe On Mon, Feb 16, 2015 at 6:59 AM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Anthony, If you are working on JIT, you should understand that declare() switch to strict typing can't improve anything, because it works on caller side and in each function you now will have to generate code for both weak and strict checks. Well, if you know the destination function at compile time, you don't need to generate generic code. you can generate a direct dispatch (asm-level function call). Right, but in real life app you almost never know what function or method you are really call. At function you also can't be sure that it always called with proper arguments. This work well only for plain function placed into a single PHP file. In this case, strict lets you push type checks back to compile time, where in non-strict mode you still need to generation runtime conversion logic. That runtime conversion logic then requires the ability to hook into Zend's error handling mechanism, vastly complicating the generated code (and the generating code). For cases when you know the called function and all passed and expected types, it's possible to use more efficient calling convention passing real arguments in CPU registers. The type checks in PHP7 is quite cheap (2-3 CPU instructions). Strict or weak check doesn't make any difference for fast path (the same 2-3 instructions). The slow patch for weak checks is going to be a bit more expensive. In fact, the research I have been doing is precisely around that (where I know for a fact that all remaining function calls are going to be typed, and compile the entire block at one time with direct calls). So that way I never need to actually do even as much as a FCC to call a userland function. Which then lets me avoid generating typing code (since I know the types). Which is why I'm advocating for strict, since that way we can treat an entire graph of function calls as strict and compile them all in one go (no need to even JIT at runtime, just compile AOT). If your research has shown something different, care to share? Very similar :), but in cases when we know the called function the effect from type hinting is negligible. It's almost always possible to generate optimal code without any hints. See code for fibo_r() from bench.php generated by our old JIT for PHP-5.5 (without type hinting): https://gist.github.com/dstogov/5f71d23f387332e9d77c Unfortunately, we didn't make the same for PHP7 yet. More important, in our experiments we saw improvements only on small benchmarks (e.g. 25 times on mandelbrot), but nothing on real-life apps. So a some point, looking into ASM code that endlessly allocates and frees zvals, we switched to engine re-factoring. According to mandel() and integer to float conversion in the loop, it's possible to perform a backward data-propagation pass to catch this case and replace integer by float in first place. We did it in our old JIT prototypes without any type hinting. Also, don't use fild, use SSE2 and/or AVX. I did wind up doing a few passes to
Re: [PHP-DEV] Remove $this from incompatible context
Hi!
Agreed. Personally, I'm a great fan of symettry, so part of me would
prefer to introduce a keyword for when you *can't* call a method
statically, e.g. instance function foo() { ... }. But I guess instance
This would be another form of saying foo() method uses $this, but if
that's true then once it uses $this you'd get the error anyway, so not
much changes from adding instance.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Spaceship operator RFC
Hi Stas, On Mon, Feb 16, 2015 at 2:20 PM, Stanislav Malyshev smalys...@gmail.com wrote: Since Andrea has withdrawn the spaceship operator RFC (https://wiki.php.net/rfc/combined-comparison-operator), I'd like to resurrect it. Looks like by vote results (with 1 day of official vote left) it was clearly passing, so are there any objections to treating it as passed? If not, I'll treat it as such and do the merging as soon as I have time. What happen to her/RFC? I know it's very frustrating if people oppose RFC. People just have different views/understandings. I hope she will be back soon. Anyway, +1 Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] I quit.
2015.02.15. 22:21 ezt írta (Andrea Faulds a...@ajf.me): Hi everyone, For my own reasons, I have decided to cease my involvement with PHP development. This isn’t a judgement of the PHP community nor the internals mailing list, you’re all wonderful people and it’s really been a pleasure, and I mean that completely honestly. However, this has ended up taking up too much of my time (which is my own fault, and my own fault alone) and I can’t really justify it to myself anymore. So, I’m no longer contributing to PHP, and all four active RFCs authored by myself are therefore withdrawn: Scalar Type Hints, Spaceship/Combined Comparison Operator, Void Return Type, Big Integer Support. The first two were in voting, so the votes have been cancelled. If anyone would like to pick up from where I left off with any of these RFCs, they are very much welcome to - there is no need to consult me first (and it’s probably for the best if you don’t). The Spaceship/Combined Comparison Operator RFC was also authored by Davey Shafik, so ask him if you want to revive that one. I’m sorry about this, but it can’t be helped. I’d rather move on to other things. I would stick around to finish everything up before I leave, but I just don’t have the time nor the motivation to finish everything. I apologise for that, especially for Scalar Type Hints as I realise this is something a lot of developers were looking forward to. I’d leave quietly, but since this affects active RFCs, I need to announce it somewhere. So, thank you, PHP community. It has been a wonderful 2 years. Goodbye. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, As you stated your reasons I'm not gonna assume otherwise. First I would like to thank you for all the contributions in these past years and that you always kept your cool, even in the long/heated discussions. And of course I hope that in the future we will see you back!
Re: [PHP-DEV] A modest proposal: __contructStatic
Am 15.02.2015 23:34 schrieb Rowan Collins rowan.coll...@gmail.com:
You can surely see how this is more readable / easier to write:
$value = MyRedir::get($key);
Actually, no, I find that harder to read accurately - there is no clue
there that there is actually a singleton under the hood, and that this is
actually an instance method in disguise.
Fair enough. You judge readabilidy by an unaccustomed reader can grasp
(better or worse) what lies behind this construct. I have a different
focus, as I'm just a herder of a small group of internal developers.
The nice thing about an explicit Singleton is you can migrate to
Dependency Injection (call $redis = MyRedis::singleton() and start
passing the instance around,
I _can_ do that with my redis class, where I need it, by calling a
method MyRedis::link() which just returns $this. But the places where I
need that are rare.
You may be able to do it with your current implementation, but how do you
propose to do it with an invisible singleton property implicitly created by
__constructStatic?
Without any caller side change, calling this already existing instance
method:
public function link() { return $this; }
OK, but you need a new subclass every time, not just a new method, or new
parameter; that limits your options. For instance, you can't dynamically
create instances based on configuration of a reusable library, which could
be as simple as adding an optional parameter to a standard Singleton:
Nothing would stop me from writing and using such a subclass, while having
fixed (in code) configuration sibling classes. Or add such a
fixed-config-singleton class method to the base class to add that to the
whole hierarchy. I don't have the need. But I could.
Any function that already uses the $redis = MyRedis::inst(); pattern
can then quickly be changed to $redis = MyRedis::inst('volatile'); and
continue to work fine.
Or, in my case, s/MyRedis::/MyRedisReg::inst('volatile')-/g. Piece of cake.
Extend was perhaps not the word I should have chosen; I was thinking of
extending the use of the class beyond the current coding pattern. By
implementing one specific use case as a magic method, you make it harder to
do anything other than that one use case; or, you end up creating a whole
set of magic methods and features, which are then no easier than just
implementing the whole thing by hand.
Nothing of that. By base class is fully flexible! It even throws an
exception when a coder tries to singleton-like use it itself - it's just
the concrete subclasses that can be used that way.
I consciously chose this nonextensibility. Of course this is (for the given
fanout of different redis servers) nothing that a public facing library
would use! I'm watching over a four man coder show writing a single web
site's code not indented for public consumption. And there, such things not
only make sense, they happen all over the place.
Anyway, I'm pretty sure that singleton subclasses are useful in various
other one-of-a-few-specializations cases for completely different uses, and
there the patterrn might just make sense, too.
I certainly understand your criticism, from a point of view of more
publically consumable codebases / libraries. Thanks for your feedback.
best regards
Patrick
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Le 05/02/2015 21:14, Andrea Faulds a écrit : Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Hi, Even if this RFC has been withdrawn, I'm posting this here, hoping it might prove useful if someone ever tries to revive it. We've discussed this RFC quite a bit with other members of AFUP, and finally ended on the +1 side. Basically, adding type-hinting for scalars goes towards a PHP that is a bit more strict -- which seems like a good thing for us. But, at the same time, the weak mode by default means users can choose to go that way at their own pace and existing code will keep working, even if calling strict libraries. The biggest concern we've had is the declare() syntax that feels a bit weird at first. But that's not enough of a concern for us to be -1 on the RFC as a whole. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A modest proposal: __contructStatic
Am 16.02.2015 02:40 schrieb Kris Craig kris.cr...@gmail.com: I've never really done any work with Redis before so I'm also having trouble understanding the use case for this given that everybody's talking about this solely in the context of Redis. Ahem, it's not everbody, just me :) And the issue comes up in the context of redis because persistent connection without keeping around yet another global $myglobalredis, and ease of use to me in that concrete case. Yeah. I had a use case. That's all. I'll rest my case soon if there are no others. best regards Patrick
Re: [PHP-DEV] [VOTE] Scalar Type Hints
We do not have Scalar type hints for years. we code in php for years without any type check. it's ok. not the primary things. Look at other dynamic programming language, they may not have the type check either. It is ok, and it is fine. Besides php, there be always other choice. If you really really need type check now. Take a look HHVM. I guest hacklang will match your need. If the PHP keep current states, my code will running till the earth dead. It works like a ancient rock. What ever , i just care my code work or not. Appreciate your time. Netroby 2015-02-16 15:30 GMT+08:00 Pascal MARTIN, AFUP mail...@pascal-martin.fr: Le 05/02/2015 21:14, Andrea Faulds a écrit : Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Hi, Even if this RFC has been withdrawn, I'm posting this here, hoping it might prove useful if someone ever tries to revive it. We've discussed this RFC quite a bit with other members of AFUP, and finally ended on the +1 side. Basically, adding type-hinting for scalars goes towards a PHP that is a bit more strict -- which seems like a good thing for us. But, at the same time, the weak mode by default means users can choose to go that way at their own pace and existing code will keep working, even if calling strict libraries. The biggest concern we've had is the declare() syntax that feels a bit weird at first. But that's not enough of a concern for us to be -1 on the RFC as a whole. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- 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] [RFC] [PRE-VOTE] Remove the date.timezone warning
I all, On Mon, Feb 16, 2015 at 2:40 PM, Stanislav Malyshev smalys...@gmail.com wrote: Are you sure that the ini file is created by the package maintainer and it includes the “date.timezone” setting is true? Last time I checked it I my experience, it is unfortunately not universally true - I've seen Linux distros with ini files that don't do that. Setting TZ correctly would require some non-trivial script work, and I'm guessing whoever did the package did not want to do this work. They could of course just put UTC there but that didn't happen either. I agree. The difficulty is choosing the right one. Linux is multi user system and users may have their own locale settings. System's default and user's default may differ also. Distributor cannot choose the right timezone automatically. If it's impossible to determine right one automatically, PHP shall have reasonable default which would be UTC. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] A modest proposal: __contructStatic
Am 16.02.2015 00:05 schrieb Rowan Collins rowan.coll...@gmail.com: A quick thought - if you want to stick with the magic static call pattern, you can implement this much more simply by doing something similar to Laravel's facades [1]: ... This basically implements in userspace what you propose to add to the language, with the only caveat being that you must separate the concerns of adding extra functionality, and wrapping it in a static facade, into two separate classes. That was one of my intermediate steps before reaching the current approach, but it irked me that when switching code from MyRedis static/singleton usage to real instance usage I suddenly have to write a different class. In my scheme, where I can use red_global::get() I can as well use $redis = new red_global(); $redis-get(); without thinking about how that companion class was named. Sure, no big issue. But a small one... By itself, surely not enough reason for a language change :) It's all a question of how many other small such uses there would be. best regards Patrick
