Re: [PHP-DEV] Constant and expression ?
On 05/19/2010 14:43, Johannes Schlüter wrote:
Hi,
On Wed, 2010-05-19 at 13:03 +0200, fqqdk wrote:
2010/5/19 Tjerk Anne Meestersdatib...@php.net
I wrote a small article that gives an idea of the speed differences:
http://shwup.blogspot.com/2010/04/about-constants.html
Unfortunately this doesn't tell, what you actually measured. And note
that as of 5.3 the class constant syntax can be used in the global
scope, too.
How about extending the usage of the 'final' keyword to support a java-like
syntax?
No. We have a const keyword. Rather somebody interested in this topic
might try to come up with a patch to at least allow constant
expressions this should serve most needs.
constant expressions might be stuff like __DIR__.'/foobar.php' or
CONST_A | CONST_B.
We already have two steps in the constant resolution for constructs like
these:
php class A { const C = FOOBAR; }
php define('FOOBAR', 42);
php echo A::C;
42
See zval_update_constant_ex in zend_API.c as a starting point. While
such an approach would also require some parser work and some clever
idea where/how to store the expression to be evaluated etc.
johannes
So, it's possible ?
Very good news.
Best regards,
Fred.
--
Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Constant and expression ?
On Wed, 2010-06-09 at 10:51 +0200, Frederic Hardy wrote: See zval_update_constant_ex in zend_API.c as a starting point. While such an approach would also require some parser work and some clever idea where/how to store the expression to be evaluated etc. So, it's possible ? Very good news. Everything is possible. The question is how maintainable the solution would be, how much of an performance impact it has etc. That I don't know. It might turn out not to be acceptable. I just gave a starting point in case somebody has the time needed for some experiments. As always: Ideas, there are many. They need developers who have time and motivation to do it. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi all:
On Wed, Jun 9, 2010 at 1:59 AM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique. It is something that
applications will frequently want to handle gracefully in order to
provide useful error messages. A new error level is needed, as is an API
/ function to obtain the failed parameter names, desired type and passed
type.
I personally don't get this error handling and weak type hinting discussion,
looks like a mix-up of type hints and input validation.
To me, type hints are a contract between an API and the consumer of the API,
reason being that it makes things a lot easier on the inside of that API
call and errors caused by misuse are caught early.
For those that don't want this contract, don't use it.. By default PHP will
behave just like you want, namely: type less.
But to me, that is not a good way for API's that are used by several
thousand developers that probably don't check the php doc every time they
use a function, and do something human; mistakes.
When PHP 5 added support for this, that made my day, even if it wasn't
complete.
It is one of the things that made PHP's OOP support a lot more on level with
other languages / platforms, and I think it is a strength that it behaves
like other platforms for those that want to use it.
So sorry, but I think Lukas' Zeev's proposal is the wrong approach, it
will make this useless for the very people that wanted it in the first
place.
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case as
consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm
not saying anyone would do this intentionally, but in a large application
you might not have full oversight and can unintentionally pass variables of
wrong type or in wrong order causing issues to surface much later as there
are no strict type checks that would detect the mistake immediately while
developing).
--
One solution (if weak type hinting is really needed) is to go back to Ilia's
proposal for virtual types and for example extend it with wint, wbool,
wstring, wfloat and similar (it could just as well be ~int, int_w or
int_cast for instance) for cases where you want to accept type by value.
This casting should be done with current type juggling rules for
consistency.
But adding cast support like this would make the whole catchable cast
error's discussion re appear. And those probably involves a lot more
overhead then handling such cases yourself inside your API functions using
exceptions, so I don't personally see any gain by this.
So to avoid that, I would say Derick's proposal to allow function foo(
(int) $bar) { } // auto-cast to int is superior as it will avoid that
discussion/issue, keep it simple not be misunderstood as a means of input
validation.
- AR
Re: [PHP-DEV] Type hinting
On 9 June 2010 00:59, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Lukas: On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote: Same deal as E_NOTICE. Either you care about them or you dont. Exactly. The type hinting situation is unique. It is something that applications will frequently want to handle gracefully in order to provide useful error messages. A new error level is needed, as is an API / function to obtain the failed parameter names, desired type and passed type. Is there anything I suggested in http://news.php.net/php.internals/48573 of use here? -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 09.06.2010, at 12:01, André Rømcke wrote: Example: function fetchById( int $id, bool $asObject = true ) If weak type hints are accepted, type hints would be useless in this case as consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm not saying anyone would do this intentionally, but in a large application you might not have full oversight and can unintentionally pass variables of wrong type or in wrong order causing issues to surface much later as there are no strict type checks that would detect the mistake immediately while developing). please read RFC's you comment on (well the following was added to the RFC 2 or maybe even 3 weeks ago): in your above example there would be data loss in the type cast and therefore there would not be silent auto casting. again there is only silent automatic casting being proposed in the case of when there is no data loss: 1 = 1 but 1abc would not silently cast to 1 etc. anyway .. can we conclude this discussion? probably best if someone who is more or less impartial would handle the call fore vote and figure out some sensible way to let people vote on the various solutions that are proposed. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi Lukas! On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote: On 09.06.2010, at 12:01, André Rømcke wrote: Example: function fetchById( int $id, bool $asObject = true ) If weak type hints are accepted, type hints would be useless in this case as consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm not saying anyone would do this intentionally, but in a large application you might not have full oversight and can unintentionally pass variables of wrong type or in wrong order causing issues to surface much later as there are no strict type checks that would detect the mistake immediately while developing). please read RFC's you comment on (well the following was added to the RFC 2 or maybe even 3 weeks ago): in your above example there would be data loss in the type cast and therefore there would not be silent auto casting. http://wiki.php.net/rfc/typecheckingstrictandweak I was assuming Option 1 for the example and the fact that E_STRICT like any other error would just be logged somehow in most systems, hence not stop the call from executing which would be an even bigger issue if it is an store() function. anyway .. can we conclude this discussion? probably best if someone who is more or less impartial would handle the call fore vote and figure out some sensible way to let people vote on the various solutions that are proposed. +1
Re: [PHP-DEV] Type hinting
On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote: On 09.06.2010, at 12:01, André Rømcke wrote: Example: function fetchById( int $id, bool $asObject = true ) If weak type hints are accepted, type hints would be useless in this case as consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm not saying anyone would do this intentionally, but in a large application you might not have full oversight and can unintentionally pass variables of wrong type or in wrong order causing issues to surface much later as there are no strict type checks that would detect the mistake immediately while developing). please read RFC's you comment on (well the following was added to the RFC 2 or maybe even 3 weeks ago): in your above example there would be data loss in the type cast and therefore there would not be silent auto casting. again there is only silent automatic casting being proposed in the case of when there is no data loss: 1 = 1 but 1abc would not silently cast to 1 etc. anyway .. can we conclude this discussion? probably best if someone who is more or less impartial would handle the call fore vote and figure out some sensible way to let people vote on the various solutions that are proposed. First step would be to gather all of the ideas and rfcs, and create a comparsion between them. At this point, there are several proposals around in the wiki, some of them are old, and outdated, but Lukas did his best to merge/compare the weak and strict proposal at http://wiki.php.net/rfc/typecheckingstrictandweak There is another proposal by myself: http://wiki.php.net/rfc/splweaktypehintingwithautoboxing And I think there were discussions about extending the parser and adding support for the Reflection to allow handling the docblocks, but I think that was just a wild idea. So before we could vote, we should sum up the ideas. - strict OR weak type hinting? (define weak, what can be converted, what happens if cannot be converted, I think Lukas already did this) - core feature OR spl? (maybe both, see the error/exception part) - trigger_error OR exceptions? (we said, that exceptions shouldn't be allowed inside the core, so maybe this can be only impelemted through spl) - if we chose trigger_error, then E_NOTICE OR E_STRICT OR ??? on type/range missmatch we should gather the pros/cons for the comparsion. there were ideas about leaving out the type hinting for scalars, but adding new/extended functionalities to allow easier variable type/range check (maybe smarter func_get_args), etc. So my 2 cents: We should chose the *best* solution which makes *most* of us happy, but we should inspect every Idea, not just the ones that have pretty RFCs. Tyrael
Re: [PHP-DEV] Type hinting
- trigger_error OR exceptions? (we said, that exceptions shouldn't be allowed inside the core, so maybe this can be only impelemted through spl) I think the exception discussion should be omitted. There exists some other RFCs to fix this issue. http://wiki.php.net/rfc/enhanced_error_handling http://wiki.php.net/rfc/errors_as_exceptions Best regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
At 02:59 09/06/2010, Daniel Convissor wrote: Hi Lukas: On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote: Same deal as E_NOTICE. Either you care about them or you dont. Exactly. The type hinting situation is unique. It is something that applications will frequently want to handle gracefully in order to provide useful error messages. A new error level is needed, as is an API / function to obtain the failed parameter names, desired type and passed type. Daniel, I think having E_TYPE (or whatever), a non-fatal notice that can be either ignored or handled separately from everything else makes sense. I think we may actually want to introduce it at the most basic levels of PHP, so that whenever data loss occurs (except for explicit casts) - an E_TYPE warning will be generated. That will bring consistency between the new type hinting and the rest of PHP. Thoughts? Dmitry prepared a patch that implements auto-converting type hinting with silent data loss. If we combine it with an infrastructure-level E_TYPE upon data loss - I think we have a pretty good solution overall. The patch is available at http://wiki.php.net/rfc/typecheckingstrictandweakhttp://wiki.php.net/rfc/typecheckingstrictandweak Regarding having an API that allows you to access the original unconverted value and/or its type - I don't think we should go in that direction. Presently this information is not retained in any way, and retaining it would be quite a headache and we'll also incur a performance penalty. If you're going to be using APIs to determine what happened to a passed argument and behave accordingly - why not simply avoid using type hinting, and perform type/value checks in the function body instead? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: TestFest 2010 News Announcement.
On Sat, Jun 5, 2010 at 11:05 PM, Eric Stewart ericleestew...@gmail.comwrote: Wrote up and attempted to commit a news announcement for TestFest 2010, only to find out I don't have karma for that section of the repository. I've attached the entry XML file if someone would be kind enough to commit it for me. Thanks, Eric Lee Stewart Can someone please commit this news item or grant me karma to do it myself? Eric Lee Stewart
Re: [PHP-DEV] Type hinting
On Wed, Jun 9, 2010 at 4:17 PM, Zeev Suraski z...@zend.com wrote: At 02:59 09/06/2010, Daniel Convissor wrote: Hi Lukas: On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote: Same deal as E_NOTICE. Either you care about them or you dont. Exactly. The type hinting situation is unique. It is something that applications will frequently want to handle gracefully in order to provide useful error messages. A new error level is needed, as is an API / function to obtain the failed parameter names, desired type and passed type. Daniel, I think having E_TYPE (or whatever), a non-fatal notice that can be either ignored or handled separately from everything else makes sense. I think we may actually want to introduce it at the most basic levels of PHP, so that whenever data loss occurs (except for explicit casts) - an E_TYPE warning will be generated. That will bring consistency between the new type hinting and the rest of PHP. Thoughts? Dmitry prepared a patch that implements auto-converting type hinting with silent data loss. If we combine it with an infrastructure-level E_TYPE upon data loss - I think we have a pretty good solution overall. The patch is available at http://wiki.php.net/rfc/typecheckingstrictandweak http://wiki.php.net/rfc/typecheckingstrictandweak Regarding having an API that allows you to access the original unconverted value and/or its type - I don't think we should go in that direction. Presently this information is not retained in any way, and retaining it would be quite a headache and we'll also incur a performance penalty. If you're going to be using APIs to determine what happened to a passed argument and behave accordingly - why not simply avoid using type hinting, and perform type/value checks in the function body instead? Zeev If we introduce the E_TYPE what will be the new default/suggested error level? If it won't be enabled by default, then maybe we could introduce this in the whole language. I mean, if you implicitly convert '123asd' to integer, you will trigger this error. for example: $foo = 0; $foo += (int)'123abc'; // no error $foo += '123abc'; // E_TYPE Tyrael
Re: [PHP-DEV] Traits and static variables
On 05.06.2010, at 22:47, Stefan Marr wrote: Hi: Was just thinking about some details of the traits implementation. From my perspective, static variables in methods should work like the method would have been actually implemented in the class using the traits. Thus, static variables should be independent for the different traits usages. Any thoughts on that? i agree. the mantra is traits are engine level automated copypaste. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting
-Original Message- From: Zeev Suraski [mailto:z...@zend.com] Sent: 09 June 2010 15:17 To: Daniel Convissor Cc: PHP Internals List Subject: Re: [PHP-DEV] Type hinting At 02:59 09/06/2010, Daniel Convissor wrote: Hi Lukas: On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote: Same deal as E_NOTICE. Either you care about them or you dont. Exactly. The type hinting situation is unique. It is something that applications will frequently want to handle gracefully in order to provide useful error messages. A new error level is needed, as is an API / function to obtain the failed parameter names, desired type and passed type. Daniel, I think having E_TYPE (or whatever), a non-fatal notice that can be either ignored or handled separately from everything else makes sense. I think we may actually want to introduce it at the most basic levels of PHP, so that whenever data loss occurs (except for explicit casts) - an E_TYPE warning will be generated. That will bring consistency between the new type hinting and the rest of PHP. Thoughts? Dmitry prepared a patch that implements auto-converting type hinting with silent data loss. If we combine it with an infrastructure-level E_TYPE upon data loss - I think we have a pretty good solution overall. The patch is available at http://wiki.php.net/rfc/typecheckingstrictandweakhttp://wiki .php.net/rfc/typecheckingstrictandweak Is E_TYPE good enough? If it follows the other E_*, I'd suggest it's not. Just having a single string error message describing the error, and having to unmangle the detailed information* from that doesn't seem that great. * Which parameter, what value, what was expected. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
Hi! Let's me take the name __create() for this example : We already have __construct for creating objects of class Foo, and if those are objects of another class, you can always have a static factory. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
On 2010-06-09 16:06:37 +0200, Ferenc Kovacs said:
In fact the uniq problem i see, is could be a name conflict like :
function Foo() {
// ...
}
class Foo() {
public __create() {
// ...
}
}
Foo(); // Instanciate the class or call the function ?
And I think that this is a much higher cost, that we gain.
If we want this functionality, then Mathieu Suen's idea is better IMHO:
http://www.mail-archive.com/internals@lists.php.net/msg46764.html
eg. (new Foo())-bar()
Tyrael
Yes my only possible objection is that's less readable.
--
Alban Leroux
s...@paradoxal.org
Web developper
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting
At 19:55 09/06/2010, Jared Williams wrote: Is E_TYPE good enough? If it follows the other E_*, I'd suggest it's not. Yes, same error mechanism. Just having a single string error message describing the error, and having to unmangle the detailed information* from that doesn't seem that great. The error here is not for the function to be able to 'recover' from that situation. The function will behave fine, since it'll still get what it expected to get (the value still gets converted to the required type). It's for the caller - indicating that wrong arguments were supplied. I can't seem to understand why it makes sense to save on type conversion and/or validation code and invest in error recovery code instead. Cluttering the function with checks into which argument was supplied, what type it had and what it was converted to would be ugly and convoluted and negate the advantage of using type hints in the first place. If you want to have some complex type validation/recovery routines, then simply implement them - don't use type hints and then design the function to recover from situations you may consider as errors. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
At 17:54 09/06/2010, Ferenc Kovacs wrote: If we introduce the E_TYPE what will be the new default/suggested error level? If it won't be enabled by default, then maybe we could introduce this in the whole language. I mean, if you implicitly convert '123asd' to integer, you will trigger this error. That's exactly what I had in mind. Have E_TYPE off by default and implement it throughout PHP - instead of just type hints. for example: $foo = 0; $foo += (int)'123abc'; // no error $foo += '123abc'; // E_TYPE Exactly. And to make sure we're on the same page: $foo += '123'; // no error Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
for example: $foo = 0; $foo += (int)'123abc'; // no error $foo += '123abc'; // E_TYPE Exactly. And to make sure we're on the same page: $foo += '123'; // no error +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi Zeev: On Wed, Jun 09, 2010 at 05:17:13PM +0300, Zeev Suraski wrote: I think having E_TYPE (or whatever), a non-fatal notice that can be either ignored or handled separately from everything else makes sense. I think we may actually want to introduce it at the most basic levels of PHP, so that whenever data loss occurs (except for explicit casts) - an E_TYPE warning will be generated. That will bring consistency between the new type hinting and the rest of PHP. Thoughts? Intersting. Knowing when data is being lost in any situation can be helpful. At the same time, guaranteeing a function call signature is somewhat different than noticing a change in the general code. Perhaps two new error types? Though that may not be practical, depending on how the engine's logic works. Regarding having an API that allows you to access the original unconverted value and/or its type - I don't think we should go in that direction. Presently this information is not retained in any way, and retaining it would be quite a headache Yeah, I don't know much about what the engine keeps track of. But I do know that E_NOTICE's tell one the name of the variable that is undefined. And debug backtraces can show one the call stack. So there's some stuff being tracked. While my initial suggestion called for tracking new information, that's not essential. Getting at the information that is available by some way other than parsing the error string with a regular expression would be really nice. why not simply avoid using type hinting, and perform type/value checks in the function body instead? That's completely doable. It seems type hinting is supposed to cut down on the need to do that. Thanks for thinking about this, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
