Re: [PHP-DEV] Type hinting
On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. Melanie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? 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
On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? regards, Lukas Kahwe Smith m...@pooteeweet.org Sure, you can create an empty interface for this scenario but only for self defined classes. All PHP classes can't used with this interface. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 18.06.2010, at 18:13, Christian Kaps wrote: On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? regards, Lukas Kahwe Smith m...@pooteeweet.org Sure, you can create an empty interface for this scenario but only for self defined classes. All PHP classes can't used with this interface. and you seriously need type hints for this use case? 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
On 18 June 2010 15:13, Melanie Rhianna Lewis cybersp...@php.net wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. Melanie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php class::method(object $instance) would certainly be useful. Could this not be solved by internally extending all userland classes (and whilst we are at this why not all internal classes) from a PHP supplied empty class? Maybe stdClass? scalar, array, class, interface, untyped class. -- - 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
Hi, I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? What is the next step to get type hinting in the next PHP release, regardless of whether strict or weak? Best regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. -- 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] Type hinting
Am 17.06.2010 21:14, schrieb Stas Malyshev: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. My view layer accepts only presentation model objects. So every object with public properties can be passed to the the view. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Zeev Suraski wrote: 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 Out of curiosity: What would you do with the E_TYPE on the last one? 1) Log it: What for? 2) Abort the script: Why? 3) Silence it with explicit casting: Why? 4) Look at the code and find out X: What is X? My guess is that it is theoretically useful if you ensure that all your normal code is E_TYPE-free and user provided input could trigger E_TYPE which would require special code to be added in that case to avoid future E_TYPE. One biggy for me: E_TYPE should not slow down PHP if one is not interested in it. I think there was a discussion about making ignored E_* (almost) performance neutral but I don't think that's implemented yet, right? We patched away E_NOTICE warnings in the PHP source because we're not interested in access to undefined variables and I wouldn't want to have to do something similar for E_TYPE. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
At 15:12 10/06/2010, Christian Schneider wrote: Zeev Suraski wrote: 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 Out of curiosity: What would you do with the E_TYPE on the last one? 1) Log it: What for? 2) Abort the script: Why? 3) Silence it with explicit casting: Why? 4) Look at the code and find out X: What is X? Exactly the same thing you'd do with notices regarding uninitialized variables. If someone turns E_TYPE on, it's a pretty strong implication that he expects his code to be 'type clean', i.e., that each and every value will be sanitized and have the correct type. Chance are that seeing an E_TYPE in such a case would prompt him to fix his code (either by silencing - unlikely - or by fixing his type/value verification. My guess is that it is theoretically useful if you ensure that all your normal code is E_TYPE-free and user provided input could trigger E_TYPE which would require special code to be added in that case to avoid future E_TYPE. Right. One biggy for me: E_TYPE should not slow down PHP if one is not interested in it. I think there was a discussion about making ignored E_* (almost) performance neutral but I don't think that's implemented yet, right? We patched away E_NOTICE warnings in the PHP source because we're not interested in access to undefined variables and I wouldn't want to have to do something similar for E_TYPE. I agree we should only add E_TYPE if it's almost performance neutral. IIRC that would require some work. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, Jun 10, 2010 at 2:12 PM, Christian Schneider cschn...@cschneid.comwrote: Zeev Suraski wrote: 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 Out of curiosity: What would you do with the E_TYPE on the last one? 1) Log it: What for? 2) Abort the script: Why? 3) Silence it with explicit casting: Why? 4) Look at the code and find out X: What is X? As for me, I would log it, and depending on the application abort or continue excetuion, and when I got the report about the error, I would look at the code... One biggy for me: E_TYPE should not slow down PHP if one is not interested in it. I think there was a discussion about making ignored E_* (almost) performance neutral but I don't think that's implemented yet, right? We patched away E_NOTICE warnings in the PHP source because we're not interested in access to undefined variables and I wouldn't want to have to do something similar for E_TYPE. The current error handling is sub-optimal. AFAIK the error handler gets called and the variables(stack trace) populated whether the given error matches the error_level, or not. So I think that thats a different problem. Tyrael
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
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] 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] 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
Re: [PHP-DEV] Type hinting
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. Thanks, --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
Re: [PHP-DEV] Type hinting
On 04.06.2010, at 03:18, Daniel Convissor wrote: On Thu, Jun 03, 2010 at 10:29:30AM -0400, Daniel Convissor wrote: Hi Folks: On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote: IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios E_STRICT doesn't cut it. And another reason E_STRICT won't serve this situation well: how are userland error handlers supposed to pick out the type hinting conversion problems from all of the other bazillion E_STRICT errors that come up? Not very efficient. Same deal as E_NOTICE. Either you care about them or you dont. Anyway, in my weak typing proposal I also made an optional variant to get an E_FATAL instead of E_STRICT, though I personally do not see the need for it. 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 Folks: On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote: IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios E_STRICT doesn't cut it. So many applications/servers out there run with E_STRICT off. Then there is the multitudes that have _all_ error handling turned off. It seems the weird conversions need to be handled differently. One possibility is creating a new function called something like set_type_hint_failure_handler() where developers can name a userland function to deal with the conversion problems. Another possibility is creating a new error level. Thanks, --Dan (Pardon me if this has been raised already. I don't know when I will be able to read the rest of the thread, so need to put this out there before the E_STRICT idea goes to too far...) -- 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
Re: [PHP-DEV] Type hinting
On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote: It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. I'd like to point out that filter_input() does cast user input to the right PHP type. And if memory serves, ext/filter is meant to be PHP's standard way of handling user input. So in terms of incoming data, I'd consider user input being covered already. The only other big source of data is the database. Unfortunately, it seems that mysqlnd experiments in using MySQL's binary protocol for all queries and not just prepared statements [1] didn't materialize. But again, the same way filter was one of PHP 5.2's highlights, mysqlnd is one of PHP 5.3's highlights and the recommended way to communicate with MySQL, which means that if mysqlnd gained that ability somewhere down the road then most of incoming data would be correctly typed already. Emphasis on would. -JD [1] http://blog.ulf-wendel.de/?p=198 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 03.06.2010, at 18:25, Josh Davis wrote: On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote: It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. I'd like to point out that filter_input() does cast user input to the right PHP type. And if memory serves, ext/filter is meant to be PHP's standard way of handling user input. So in terms of incoming data, I'd consider user input being covered already. The only other big source of data is the database. Unfortunately, it seems that mysqlnd experiments in using MySQL's binary protocol for all queries and not just prepared statements [1] didn't materialize. But again, the same way filter was one of PHP 5.2's highlights, mysqlnd is one of PHP 5.3's highlights and the recommended way to communicate with MySQL, which means that if mysqlnd gained that ability somewhere down the road then most of incoming data would be correctly typed already. Emphasis on would. Thats all fine and dandy if the ultimate goal is to turn PHP into a strictly typed language and of course if 90% of the API's you talk to require strict typing, then the question becomes why even use a dynamic language to begin with? Why not clean all of that magic out, get better memory management, less overhead in plenty of places, less chances for typos to result in hard to debug issues. Sure sounds good and I guess there probably is a market, maybe even an urgent need for a strictly typed scripting language for the web space. But really is PHP the best basis for this? 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
On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote: On 03.06.2010, at 18:25, Josh Davis wrote: On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote: It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. I'd like to point out that filter_input() does cast user input to the right PHP type. And if memory serves, ext/filter is meant to be PHP's standard way of handling user input. So in terms of incoming data, I'd consider user input being covered already. The only other big source of data is the database. Unfortunately, it seems that mysqlnd experiments in using MySQL's binary protocol for all queries and not just prepared statements [1] didn't materialize. But again, the same way filter was one of PHP 5.2's highlights, mysqlnd is one of PHP 5.3's highlights and the recommended way to communicate with MySQL, which means that if mysqlnd gained that ability somewhere down the road then most of incoming data would be correctly typed already. Emphasis on would. Thats all fine and dandy if the ultimate goal is to turn PHP into a strictly typed language and of course if 90% of the API's you talk to require strict typing, then the question becomes why even use a dynamic language to begin with? Why not clean all of that magic out, get better memory management, less overhead in plenty of places, less chances for typos to result in hard to debug issues. Sure sounds good and I guess there probably is a market, maybe even an urgent need for a strictly typed scripting language for the web space. But really is PHP the best basis for this? regards, Lukas Kahwe Smith m...@pooteeweet.org Sorry, I missed the point when Josh was suggesting to turn PHP into a strictly typed language. I think that you should have noted, that what suggestion/idea are you against it. Converting the variable type to the appropriate one? Or the strict type hinting? Tyrael ps: http://en.wikipedia.org/wiki/Straw_man Straw man arguments often arise in public debates such as a (hypothetical) prohibition http://en.wikipedia.org/wiki/Prohibition debate: Person A: *We should liberalise the laws on beerhttp://en.wikipedia.org/wiki/Beer .*Person B: *No, any society with unrestricted access to intoxicants loses its work ethic and goes only for immediate gratification.* The proposal was to relax laws on beer. Person B has exaggerated this to a position harder to defend, i.e., unrestricted access to intoxicants.[1]http://en.wikipedia.org/wiki/Straw_man#cite_note-book-0
Re: [PHP-DEV] Type hinting
On 03.06.2010, at 18:57, Ferenc Kovacs wrote: On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 03.06.2010, at 18:25, Josh Davis wrote: On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote: It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. I'd like to point out that filter_input() does cast user input to the right PHP type. And if memory serves, ext/filter is meant to be PHP's standard way of handling user input. So in terms of incoming data, I'd consider user input being covered already. The only other big source of data is the database. Unfortunately, it seems that mysqlnd experiments in using MySQL's binary protocol for all queries and not just prepared statements [1] didn't materialize. But again, the same way filter was one of PHP 5.2's highlights, mysqlnd is one of PHP 5.3's highlights and the recommended way to communicate with MySQL, which means that if mysqlnd gained that ability somewhere down the road then most of incoming data would be correctly typed already. Emphasis on would. Thats all fine and dandy if the ultimate goal is to turn PHP into a strictly typed language and of course if 90% of the API's you talk to require strict typing, then the question becomes why even use a dynamic language to begin with? Why not clean all of that magic out, get better memory management, less overhead in plenty of places, less chances for typos to result in hard to debug issues. Sure sounds good and I guess there probably is a market, maybe even an urgent need for a strictly typed scripting language for the web space. But really is PHP the best basis for this? regards, Lukas Kahwe Smith m...@pooteeweet.org Sorry, I missed the point when Josh was suggesting to turn PHP into a strictly typed language. I think that you should have noted, that what suggestion/idea are you against it. Converting the variable type to the appropriate one? Or the strict type hinting? Tyrael ps: http://en.wikipedia.org/wiki/Straw_man Straw man arguments often arise in public debates such as a (hypothetical) prohibition debate: Person A: We should liberalise the laws on beer. Person B: No, any society with unrestricted access to intoxicants loses its work ethic and goes only for immediate gratification. The proposal was to relax laws on beer. Person B has exaggerated this to a position harder to defend, i.e., unrestricted access to intoxicants.[1] You didnt read my email: I was saying that focusing PHP API's on consuming and returning strict types _would_ make sense if the language would be strictly typed. I did not suggest that Josh was implying that, which is part of why I have an issue with his post. Or in other words I was saying he isnt going _far_ enough, though if he did go far enough to make things worthwhile, then this is not the right place, because PHP is not the right basis. Or in yet other words, I think a strict typed dynamic web oriented programming language has merit, just that PHP is not the right language to start from if that is what you want to design. I could probably find some wikipedia article to reference in order to misrepresent your reply, but I will hold off on that. 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
On 3 June 2010 18:25, Josh Davis php...@gmail.com wrote: seems that mysqlnd experiments in using MySQL's binary protocol for all queries and not just prepared statements [1] didn't materialize. I have to correct myself here, the MYSQLI_OPT_INT_AND_FLOAT_NATIVE option did materialize, so native typing through mysqlnd only seems to require one call to $mysql-options() On 3 June 2010 18:32, Lukas Kahwe Smith m...@pooteeweet.org wrote: Thats all fine and dandy if the ultimate goal is to turn PHP into a strictly typed language and of course if 90% of the API's you talk to require strict typing, then the question becomes why even use a dynamic language to begin with? One of PHP's strength is that if you don't want to bother with variable types you don't have to, but if you want to then you should be able to without an incessant use of userspace validation. I'm glad that PHP lets me concatenate an integer and a string (or even echo an integer for that matter) but at the same time if I'm using an int typehint then I strongly hope that all that will get through will be an int variable. I see typehints as a sanity check, to be used in situations where I know that the only way for the wrong type to get passed is because of a bug. So why PHP? Because it allows to write tons of stuff very easily. And wherever you want more control you can have it too. As Ferenc Kovacs pointed out, saying that wanting strict typehints means wanting to turn PHP into a strictly typed language is as absurd as claiming that proponents of a more relaxed typehinting would lead to eliminating the integer type altogether because 1 + 2 behaves as expected anyway. I'm sure that nobody wants to go that far on either end of the spectrum. This isn't about ideology, this is about practicality. A strictly typed PHP is impractical. And for me, an integer typehint that doesn't differentiate between strings and integers is impractical. -JD -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, 03 Jun 2010 17:25:53 +0100, Josh Davis php...@gmail.com wrote: On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote: It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. I'd like to point out that filter_input() does cast user input to the right PHP type. And if memory serves, ext/filter is meant to be PHP's standard way of handling user input. So in terms of incoming data, I'd consider user input being covered already. The only other big source of data is the database. [...] User input and databases are certainly not the only sources of incoming data – think for instance about (possibly already dtd/schema validated) XML. Another example with dates: $d1 = new DateTime(2010-06-01); $d2 = new DateTime(2010-07-01); my_func($d1-format(w)); my_func2($d2-diff($d1)-format(%d)); I'm sure it wouldn't be hard to find other examples outside form submissions and databases. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 3 June 2010 22:24, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Thu, 03 Jun 2010 17:25:53 +0100, Josh Davis php...@gmail.com wrote: The only other big source of data is the database. [...] Emphasis on big. There's an infinite number of sources (from mashups using XML or JSON to XML-RPC servers or weird setups processing CSV files), some of them can be/are typed, others are not. The two big sources of incoming data are user input and databases, though. And remember that I was only discussing it in response to the claim that almost all incoming data for PHP are strings. My point was that user input will be correctly typed if you validate it with PHP's bundled extension, as it is commonly recommended, and it's also becoming increasingly easy to get correctly typed data from your database thanks to mysqlnd. Of course it doesn't mean that you won't find some rarer situations where you get strings in place of integers, e.g. if you're reading from a CSV or XML file, or from a database that only uses a text protocol. -JD -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! And remember that I was only discussing it in response to the claim that almost all incoming data for PHP are strings. My point was that user input will be correctly typed if you validate it with PHP's bundled extension, as it is commonly recommended, and it's also Validation and typing are entirely different things. Many validation methods do not require or provide strict typing. becoming increasingly easy to get correctly typed data from your database thanks to mysqlnd. Of course it doesn't mean that you won't Did you just equate databases to mysqlnd? And the notion of correctly typed data only makes sense in a strictly typed language. -- 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] Type hinting
On 3 June 2010 23:37, Stas Malyshev smalys...@sugarcrm.com wrote: Validation and typing are entirely different things. Many validation methods do not require or provide strict typing. I can't agree more and that's exactly why I want typehints to only check for type, not validate the content of a variable. An integer typehint should just check for the integer type, not check whether a string would be a valid number. I don't know about those many validation methods, I'm only saying that PHP's bundled validation functions do enforce typing. Did you just equate databases to mysqlnd? And the notion of correctly typed data only makes sense in a strictly typed language. Did you just intentionally misrepresent my position by quoting just enough words to create an argument? Obviously, mysqlnd only helps if you're using it. So it won't work if you're using MySQL through libmysql (still MySQL) or if your database only supports text, as I was saying a few words below what you quoted. You said almost all incoming data for PHP are strings. This is incorrect. PHP's own input validation returns non-strings, and PHP's MySQL native driver optionally returns non-strings. Yet, you don't see me claiming that almost all incoming data for PHP is typed. A lot of it is optionally typed. Evidently, typehints too, are optional. -JD -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, Jun 03, 2010 at 10:29:30AM -0400, Daniel Convissor wrote: Hi Folks: On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote: IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios E_STRICT doesn't cut it. And another reason E_STRICT won't serve this situation well: how are userland error handlers supposed to pick out the type hinting conversion problems from all of the other bazillion E_STRICT errors that come up? Not very efficient. Thanks, --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
Re: [PHP-DEV] Type hinting
On Wed, Jun 2, 2010 at 12:49 AM, Chad Fulton chadful...@gmail.com wrote: Hello! As I mentioned, I think that we have to inform the caller about the problem (be either a type or a conversion mismatch), so the only options to trigger an error, or throw an exception. I like the exception idea better, because it can be easily handled localy (no need to register a global error handler), but as the core devs said, it isn't allowed to throw exceptions from the core, so this is why I think, that the weak type hinting should be implemented as an spl interface. This way we could even support array - ArrayObject conversion too. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing I'm not sure what is being added by using the SPL interface except a way to justify throwing exceptions on type mismatch with data loss? The only reason I can think of for throwing exceptions in this case would be data validation purposes, which I think is not the intention of type hinting, and also not the intention of exceptions (users inputting bad data is not an *exceptional* occurrence imo). Is there some other reason / use case for wanting exceptions? So, I mean, where is the use case where '123abc' will be passed to a type-hinted field where you could catch the exception and do something meaningful to carry on with the execution of the program other than simply error-ing out? I think I *did* mentioned, why I prefer exceptions over errors. The first thing is, that you han handle the exception in the original scope, so you have all the avaiable data to carry out your decision about the error. Maybe you want to log that faulty record, then continue the batch processing, which was just interrupted. With trigger_error, the error handling happens in a new empty scope plus it's not a trivial task to do the cleanup(flag the mismatching record in the db to human review) and resuming the original batch operation. Plus, usually, if you are using objects, and spl interfaces (which has its own set of default exceptions) there is a high chance, that you will use exceptions, to handle the errors, so it comes natural to me, that we don't need a mixed set of error handling methods. Tyrael
Re: [PHP-DEV] Type hinting
Hi! 2010/6/2 Stas Malyshev smalys...@sugarcrm.com Hi! Is there some other reason / use case for wanting exceptions? So, I mean, where is the use case where '123abc' will be passed to a type-hinted field where you could catch the exception and do something meaningful to carry on with the execution of the program other than simply error-ing out? Pretty much everywhere. Suppose you have form with, say, 2 fields and first field does not validate. Maybe you want to check the second field too and give the user both errors if they are both wrong? In general, looking at strict typing as user input validation mechanism is a very bad idea. There are specialized use input validation functions/classes/frameworks, and one should use them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I agree with you. The type hinting is not a replacement for the sanity check of the user input but a proper way of defining what type of data your functions should work with, so it's OK to trigger errors when data loss happens. When you have function foo(int $bar) the data loss will affect the application in the same way that an undefined var would do; so the E_NOTICE error level seems the best approach to me. And when the data conversion is not possible (e.g. object to numeric) just trigger an E_FATAL. Let the top level users take care of the input because I think that language features like this type hinting are for the low level of the development. Regards, Eloy Bote Falcón.
Re: [PHP-DEV] Type hinting
Hi! The optional scalar type hinting would raise a catchable fatal error that could be converted to an exception. If you advocate moving PHP to full-OO with exceptions as primary error handling mechanism, it's fine - but there would be nothing optional or hinting about it - once you have one piece of code doing it, you'd have to have all code that touches it (and all code that touches that code, etc.) to be strict typed and exception-controlled. And then you'd want typed variables and throws clause to methods. Maybe we better rename PHP into Java and be done with it? :) -- 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] Type hinting
On Tue, Jun 1, 2010 at 7:55 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! The optional scalar type hinting would raise a catchable fatal error that could be converted to an exception. If you advocate moving PHP to full-OO with exceptions as primary error handling mechanism, it's fine - but there would be nothing optional or hinting about it - once you have one piece of code doing it, you'd have to have all code that touches it (and all code that touches that code, etc.) to be strict typed and exception-controlled. And then you'd want typed variables and throws clause to methods. Maybe we better rename PHP into Java and be done with it? :) type hinting for arrays and objects does the same (catchable fatal error on mismatch), whats the difference? if you start using a piece of code, which uses type hinting for non-scalar variables, you already have to deal with this kind of situation (custom error handler, or catching the exception) So from my point of view, you are arguing against the type hinting itself, which is too late IMHO. Tyrael
Re: [PHP-DEV] Type hinting
Hi! type hinting for arrays and objects does the same (catchable fatal error on mismatch), whats the difference? if you start using a piece of code, which uses type hinting for non-scalar variables, you already have to deal with this kind of situation (custom error handler, or catching the exception) The difference is it is very rare that you pass object of one class instead of another, and it is usually an obvious mistake (like using wrong variable, etc.). It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. So you may get by with basically ignoring class types since you'd almost never would have to handle failure in your app. With scalar strict typing, you'd most certainly have to handle failures. Also, it never makes sense to convert one object type into another, and almost never this operation can be defined. On the other hand, scalar types are very frequently converted in PHP and generally considered rather interchangeable in other dynamic languages. Nobody would refuse to understand that IS_INTEGER:0 and IS_BOOL:0 is the same and mean false. If you make your application have this distinction, you'd have to code for it in a way that never was what PHP is about. So from my point of view, you are arguing against the type hinting itself, which is too late IMHO. No it is not too late. It is never too late to stop PHP from turning into Java wannabe. If you want strictly-typed exclusively-OO language, you know where to find them. -- 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] Type hinting
On Tue, Jun 1, 2010 at 8:43 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
type hinting for arrays and objects does the same (catchable fatal error
on mismatch), whats the difference?
if you start using a piece of code, which uses type hinting for
non-scalar variables, you already have to deal with this kind of
situation (custom error handler, or catching the exception)
The difference is it is very rare that you pass object of one class instead
of another, and it is usually an obvious mistake (like using wrong variable,
etc.). It is very frequent that you want number and get 1 instead - almost
all incoming data for PHP are strings.
Occasionally, I used to forget, that my arrays get converted object if I
jsonize them back and forth, and sometimes I forget, that my fetched mysql
row is an array or an object, but maybe thats me.
But I agree with you, so I also think, that we should go for the weak type
hinting with scalars.
So you may get by with basically ignoring class types since you'd almost
never would have to handle failure in your app. With scalar strict typing,
you'd most certainly have to handle failures.
I think that with weak type hinting, the only cases, when you should get an
error/exception is when you pass a scalar, which cannot be converted to the
hinted type('123abc' hinted as an int, or 1.3 hinted as an int)
Also, it never makes sense to convert one object type into another, and
almost never this operation can be defined.
array and ArrayObject?
On the other hand, scalar types are very frequently converted in PHP and
generally considered rather interchangeable in other dynamic languages.
Nobody would refuse to understand that IS_INTEGER:0 and IS_BOOL:0 is the
same and mean false. If you make your application have this distinction,
you'd have to code for it in a way that never was what PHP is about.
Agree, we are used to it.
So from my point of view, you are arguing against the type hinting
itself, which is too late IMHO.
No it is not too late. It is never too late to stop PHP from turning into
Java wannabe. If you want strictly-typed exclusively-OO language, you know
where to find them.
I mean it's too late to argue about that the current type hinting triggers
an error in case of type mismatch.
My previous mail was about that we shouldn't implement the weak type hinting
to allow silent truncation on type conversion.
Tyrael
Re: [PHP-DEV] Type hinting
Hi! Also, it never makes sense to convert one object type into another, and almost never this operation can be defined. array and ArrayObject? This is a good example because strict typing would probably reject ArrayObject passed as array, thus defeating the whole purpose of having ArrayObject. That's exactly why we have to be very careful with strict types in dynamic language - because it makes excellent dynamic extensions line ArrayObject, __toString, etc. useless - since you can not really use one type instead of another as they intend, strict typing kills that. Coercive typing, on the other hand, would work just fine with those. I mean it's too late to argue about that the current type hinting triggers an error in case of type mismatch. Actually we could change it if we wanted to, I don't believe there's really some code that relies on it being error for some functionality. The question is what we'd change it to, for which I have no good answer. -- 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] Type hinting
On Tue, Jun 1, 2010 at 10:11 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Also, it never makes sense to convert one object type into another, and almost never this operation can be defined. array and ArrayObject? This is a good example because strict typing would probably reject ArrayObject passed as array, thus defeating the whole purpose of having ArrayObject. Yeah, I know, this is why I said. That's exactly why we have to be very careful with strict types in dynamic language - because it makes excellent dynamic extensions line ArrayObject, __toString, etc. useless - since you can not really use one type instead of another as they intend, strict typing kills that. Coercive typing, on the other hand, would work just fine with those. Agree. I mean it's too late to argue about that the current type hinting triggers an error in case of type mismatch. Actually we could change it if we wanted to, I don't believe there's really some code that relies on it being error for some functionality. The question is what we'd change it to, for which I have no good answer. As I mentioned, I think that we have to inform the caller about the problem (be either a type or a conversion mismatch), so the only options to trigger an error, or throw an exception. I like the exception idea better, because it can be easily handled localy (no need to register a global error handler), but as the core devs said, it isn't allowed to throw exceptions from the core, so this is why I think, that the weak type hinting should be implemented as an spl interface. This way we could even support array - ArrayObject conversion too. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing The rfc name sucks, but I couldn't come up with a better one. Tyrael
Re: [PHP-DEV] Type hinting
Hello! As I mentioned, I think that we have to inform the caller about the problem (be either a type or a conversion mismatch), so the only options to trigger an error, or throw an exception. I like the exception idea better, because it can be easily handled localy (no need to register a global error handler), but as the core devs said, it isn't allowed to throw exceptions from the core, so this is why I think, that the weak type hinting should be implemented as an spl interface. This way we could even support array - ArrayObject conversion too. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing I'm not sure what is being added by using the SPL interface except a way to justify throwing exceptions on type mismatch with data loss? The only reason I can think of for throwing exceptions in this case would be data validation purposes, which I think is not the intention of type hinting, and also not the intention of exceptions (users inputting bad data is not an *exceptional* occurrence imo). Is there some other reason / use case for wanting exceptions? So, I mean, where is the use case where '123abc' will be passed to a type-hinted field where you could catch the exception and do something meaningful to carry on with the execution of the program other than simply error-ing out? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! Is there some other reason / use case for wanting exceptions? So, I mean, where is the use case where '123abc' will be passed to a type-hinted field where you could catch the exception and do something meaningful to carry on with the execution of the program other than simply error-ing out? Pretty much everywhere. Suppose you have form with, say, 2 fields and first field does not validate. Maybe you want to check the second field too and give the user both errors if they are both wrong? In general, looking at strict typing as user input validation mechanism is a very bad idea. There are specialized use input validation functions/classes/frameworks, and one should use them. -- 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] Type hinting
Hi! Pretty much everywhere. Suppose you have form with, say, 2 fields and first field does not validate. Maybe you want to check the second field too and give the user both errors if they are both wrong? In general, looking at strict typing as user input validation mechanism is a very bad idea. There are specialized use input validation functions/classes/frameworks, and one should use them. Right, that was my point. I can't think of any good reason to use exceptions rather than global errors (E_NOTICE or E_STRICT or similar), but some people seem to want exceptions. I was asking them if they had use valid cases (e.g. *not* data validation or similar which is undoubtably foolish) that would merit using exceptions rather than the global error handling. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Wed, Jun 2, 2010 at 7:41 AM, Chad Fulton chadful...@gmail.com wrote: Hi! Pretty much everywhere. Suppose you have form with, say, 2 fields and first field does not validate. Maybe you want to check the second field too and give the user both errors if they are both wrong? In general, looking at strict typing as user input validation mechanism is a very bad idea. There are specialized use input validation functions/classes/frameworks, and one should use them. Right, that was my point. I can't think of any good reason to use exceptions rather than global errors (E_NOTICE or E_STRICT or similar), but some people seem to want exceptions. I was asking them if they had use valid cases (e.g. *not* data validation or similar which is undoubtably foolish) that would merit using exceptions rather than the global error handling. Regardless of whether it's used for validation (which I agree is a bad idea), type errors may still occur elsewhere in the code; being able to handle those errors using exceptions has the advantage of keeping the context; a custom error handler lacks this and wouldn't be able to distinguish between errors, let alone be able to show the end-user any decent feedback. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
I remember Marcus worked on something like that some time ago. Might still
be into SVN or somewhere I think.
Julien
On Sat, May 29, 2010 at 9:03 PM, Ferenc Kovacs i...@tyrael.hu wrote:
On Sat, May 29, 2010 at 7:34 PM, Zeev Suraski z...@zend.com wrote:
At 20:28 29/05/2010, Chris Stockton wrote:
My biggest issue as a user is the fatal errors. Why are we blowing up on
something that should throw some kind of useful argument exception? I
end up
in my applications using instanceof everywhere because their is
important
cleanup to be done before the end of the request. For example I can't
afford
for php to just blow up in our account setup script, we are reaching out
to
multiple non-transactional external resources. Some of our long running
command line processes have the same issue. I am all for type hinting
but
the fatal errors or catchabale fatal errors are just silly. Exceptions
make so much more sense to me.
IMHO we shouldn't be getting to any kind of fatal error/exception
situation, which is why I like the idea of auto-conversion plus E_STRICT
in
the 'weird conversion' scenarios (the API function shouldn't care - it
got
what it asked for; The caller would get notified that he passed
something
that probably doesn't make sense).
But as to why errors and not exceptions - we have a guideline that
language
constructs don't through exceptions. It's up to users whether they want
to
use exceptions or not.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm thinking about the type hinting in php for a while, and there is my 2
cent about this.
As an API developer, I need a way, to easily force my input into a proper
type, with ease, without dataloss, and without code duplication.
As an API consumer, I don't want to bother much about my API calls, as long
as my passed arguments are in the accepted form(I don't want to
convert '123' into 123), and I don't want to create yet another custom
error
handler, to fetch the potentially triggered errors, and I cannot allow,
that
one unhandled catcable fatal error ruin my application.
So basically I need type jugling(weak type hinting) + exceptions instead of
catchable errors.
But I know that the core should't throw exceptions, so we can't go to that
direction.
What if we introduce a new spl interface, which propose auto boxing for the
scalar types + exceptions for the type missmatch.
I mean, if you call that class with scalar arguments, the scalar values
will
be converted to the matching spl class instance.
This way, you could hint your types for the interface without forcing the
api consumer to bother to convert '123' to 123 before passing it to the
method.
But if the consumer passes '123abc' when I'm hinting SplInt, then it will
throw an InvalidArgumentException or such.
So for example:
class foo implements WeakTypeHinting{
public function bar(SplInt $baz){
return $baz++;
}
}
$foo = new foo;
echo $foo-bar(1);
// 2
echo $foo-bar('2');
// 3
echo $foo-bar('3a')
// InvalidArgumentException
Feel free to discuss.
Tyrael
Re: [PHP-DEV] Type hinting
On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: On 28.05.2010, at 11:22, Etienne Kneuss wrote: so, it would be nice to update the RFC(s), so that we have a solid ground on which we can discuss/vote. i agree. i currently see 5 fundamental different options on the table: 1) current trunk 2) current trunk but only with scalar/numeric type support 3) weak typing with current PHP conversion rules that raise an E_STRICT on data loss 4) weak typing with new conversion rules 5) some syntax to allow both one of 1)/2) and 3)/4)/5) i can take care of 3), 4) and 5) over the weekend, though for 4b) (see below) i would like to get some feedback from others other than that i agree that we have beat this horse long enough that we can then pretty quickly move to a vote. that being said, i think we should do the vote by allowing people to then sort the RFC's in order of preference with the option of leaving options out that they want to veto. of course if 6) gets voted for we would then have to decide on which of the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second vote. ok .. i adjusted the weak type hinting RFC to cover 3) and 4). so i guess it would be nice if someone could create and RFC for 2) (as I guess the strict typing RFC covers 1)?) and if someone believes in a combined approach (Derick?) create an RFC for 5). if someone wants to do an SPL based exception approach, feel free to create a new RFC. 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
On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote: On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: On 28.05.2010, at 11:22, Etienne Kneuss wrote: so, it would be nice to update the RFC(s), so that we have a solid ground on which we can discuss/vote. i agree. i currently see 5 fundamental different options on the table: 1) current trunk 2) current trunk but only with scalar/numeric type support 3) weak typing with current PHP conversion rules that raise an E_STRICT on data loss 4) weak typing with new conversion rules 5) some syntax to allow both one of 1)/2) and 3)/4)/5) i can take care of 3), 4) and 5) over the weekend, though for 4b) (see below) i would like to get some feedback from others other than that i agree that we have beat this horse long enough that we can then pretty quickly move to a vote. that being said, i think we should do the vote by allowing people to then sort the RFC's in order of preference with the option of leaving options out that they want to veto. of course if 6) gets voted for we would then have to decide on which of the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second vote. ok .. i adjusted the weak type hinting RFC to cover 3) and 4). so i guess it would be nice if someone could create and RFC for 2) (as I guess the strict typing RFC covers 1)?) and if someone believes in a combined approach (Derick?) create an RFC for 5). if someone wants to do an SPL based exception approach, feel free to create a new RFC. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing Sorry for my poor english grammar, feel free to correct/expand/challenge it. Tyrael
Re: [PHP-DEV] Type hinting
Well at least I fixed the splweaktypehintingwithautoboxing for the function to return ++$var instead of $var++ which couldn't make it ;-) Julien On Mon, May 31, 2010 at 5:54 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: On 28.05.2010, at 11:22, Etienne Kneuss wrote: so, it would be nice to update the RFC(s), so that we have a solid ground on which we can discuss/vote. i agree. i currently see 5 fundamental different options on the table: 1) current trunk 2) current trunk but only with scalar/numeric type support 3) weak typing with current PHP conversion rules that raise an E_STRICT on data loss 4) weak typing with new conversion rules 5) some syntax to allow both one of 1)/2) and 3)/4)/5) i can take care of 3), 4) and 5) over the weekend, though for 4b) (see below) i would like to get some feedback from others other than that i agree that we have beat this horse long enough that we can then pretty quickly move to a vote. that being said, i think we should do the vote by allowing people to then sort the RFC's in order of preference with the option of leaving options out that they want to veto. of course if 6) gets voted for we would then have to decide on which of the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second vote. ok .. i adjusted the weak type hinting RFC to cover 3) and 4). so i guess it would be nice if someone could create and RFC for 2) (as I guess the strict typing RFC covers 1)?) and if someone believes in a combined approach (Derick?) create an RFC for 5). if someone wants to do an SPL based exception approach, feel free to create a new RFC. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing Sorry for my poor english grammar, feel free to correct/expand/challenge it. Tyrael
Re: [PHP-DEV] Type hinting
thank you, btw. I don't know how did that happen, I copypasted from my previous post, which has $var++ in it :) Tyrael On Mon, May 31, 2010 at 7:06 PM, Julien Pauli jpa...@php.net wrote: Well at least I fixed the splweaktypehintingwithautoboxing for the function to return ++$var instead of $var++ which couldn't make it ;-) Julien On Mon, May 31, 2010 at 5:54 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: On 28.05.2010, at 11:22, Etienne Kneuss wrote: so, it would be nice to update the RFC(s), so that we have a solid ground on which we can discuss/vote. i agree. i currently see 5 fundamental different options on the table: 1) current trunk 2) current trunk but only with scalar/numeric type support 3) weak typing with current PHP conversion rules that raise an E_STRICT on data loss 4) weak typing with new conversion rules 5) some syntax to allow both one of 1)/2) and 3)/4)/5) i can take care of 3), 4) and 5) over the weekend, though for 4b) (see below) i would like to get some feedback from others other than that i agree that we have beat this horse long enough that we can then pretty quickly move to a vote. that being said, i think we should do the vote by allowing people to then sort the RFC's in order of preference with the option of leaving options out that they want to veto. of course if 6) gets voted for we would then have to decide on which of the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second vote. ok .. i adjusted the weak type hinting RFC to cover 3) and 4). so i guess it would be nice if someone could create and RFC for 2) (as I guess the strict typing RFC covers 1)?) and if someone believes in a combined approach (Derick?) create an RFC for 5). if someone wants to do an SPL based exception approach, feel free to create a new RFC. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing Sorry for my poor english grammar, feel free to correct/expand/challenge it. Tyrael
[PHP-DEV] Type hinting / auto-conversion suggestion.
Hi.
This is one of those out there ideas. Not sure about the feasibility of it.
So ...
Currently, there are not a massive number of functions that can detail
what has been supplied to a function. Currently, the most useful is
func_get_args().
func_get_args() has no parameters and simply returns what has been supplied.
Would the following core amendments be possible/feasible/etc.
1 - Enhance func_get_args() to ...
array func_get_args([bool $verbose = false])
The verbose option returns an array, where each element contains ...
[supplied_value]
[supplied_type]
[received_value]
[received_type]
[clean_conversion]
2 - Introduce a new function ...
bool func_args_match_hints()
Simply a true/false if the conversion were clean.
3 - If E_STRICT is not active, then there are no
errors/warnings/notices for the consumer.
4 - If E_STRICT is active, then notices for conversions that are not 100%.
5 - Boolean castings must be treated in the same way that PHP would
handle it in an if() clause.
e.g. if (0), if ('') and if(false) are all valid boolean false.
Everything else is boolean true and essentially you cannot fail a
boolean conversion.
6 - Possibly a truebool type if a === bool test is needed ( but I
don't think so really ).
To me, it would seem that the API developer can call a single function
to determine if the parameters were cleanly converted.
The API consumer (if running E_STRICT) can take advantage of the hints
and notices.
So, even though hinting is optional, a consumer would operate in
exactly the same way. E_STRICT provides the additional information to
the consumer.
The onus is still on the developer to deal with what has been
supplied, but core is assisting in this by casting and recording what
happens.
Regards,
Richard.
--
-
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
Am 28.05.2010 20:07, schrieb Stas Malyshev: On top of that, your boilerplate throws exception. Strict typing would error out. That's very different thing (exceptions can be handled hierarchically, errors can't). So replacing that with strict type probably won't do the same. The optional scalar type hinting would raise a catchable fatal error that could be converted to an exception. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
My biggest issue as a user is the fatal errors. Why are we blowing up on something that should throw some kind of useful argument exception? I end up in my applications using instanceof everywhere because their is important cleanup to be done before the end of the request. For example I can't afford for php to just blow up in our account setup script, we are reaching out to multiple non-transactional external resources. Some of our long running command line processes have the same issue. I am all for type hinting but the fatal errors or catchabale fatal errors are just silly. Exceptions make so much more sense to me. -Chris On May 29, 2010 10:19 AM, Zeev Suraski z...@zend.com wrote: At 11:33 29/05/2010, Sebastian Bergmann wrote: The optional scalar type hinting [snip] Sebastian, I understand why proponents of strict typing are putting 'optional' next to it to suggest that people don't have to use it, ergo those who don't intend to use it shouldn't care. As numerous people (myself included) explained, any feature we add to the language ends up being necessary for users to understand - far beyond those who may have wanted to intentionally use it in the first place. Of course it's optional. Using for loops is also optional - nobody forces you to use them. Even functions are optional. Objects? Completely optional. Why ont add some optional Ruby syntax support, along with optional Perl syntax support? Optional malloc() free() functions? Optional pointer arithmetic? Those who don't want to use it wouldn't have to. Let's not fool ourselves by saying an optional feature doesn't bring clutter to the language. It does. Auto-converting type hints included - but unlike strict type checking - the value they bring is arguably higher than the clutter complexity associated with them. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.ne...
Re: [PHP-DEV] Type hinting
At 20:28 29/05/2010, Chris Stockton wrote: My biggest issue as a user is the fatal errors. Why are we blowing up on something that should throw some kind of useful argument exception? I end up in my applications using instanceof everywhere because their is important cleanup to be done before the end of the request. For example I can't afford for php to just blow up in our account setup script, we are reaching out to multiple non-transactional external resources. Some of our long running command line processes have the same issue. I am all for type hinting but the fatal errors or catchabale fatal errors are just silly. Exceptions make so much more sense to me. IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios (the API function shouldn't care - it got what it asked for; The caller would get notified that he passed something that probably doesn't make sense). But as to why errors and not exceptions - we have a guideline that language constructs don't through exceptions. It's up to users whether they want to use exceptions or not. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
At 20:34 29/05/2010, Zeev Suraski wrote: At 20:28 29/05/2010, Chris Stockton wrote: My biggest issue as a user is the fatal errors. Why are we blowing up on something that should throw some kind of useful argument exception? I end up in my applications using instanceof everywhere because their is important cleanup to be done before the end of the request. For example I can't afford for php to just blow up in our account setup script, we are reaching out to multiple non-transactional external resources. Some of our long running command line processes have the same issue. I am all for type hinting but the fatal errors or catchabale fatal errors are just silly. Exceptions make so much more sense to me. IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios (the API function shouldn't care - it got what it asked for; The caller would get notified that he passed something that probably doesn't make sense). But as to why errors and not exceptions - we have a guideline that language constructs don't through exceptions. It's up to users whether they want to use exceptions or not. s/through/throw, oops :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Sat, May 29, 2010 at 7:34 PM, Zeev Suraski z...@zend.com wrote:
At 20:28 29/05/2010, Chris Stockton wrote:
My biggest issue as a user is the fatal errors. Why are we blowing up on
something that should throw some kind of useful argument exception? I end up
in my applications using instanceof everywhere because their is important
cleanup to be done before the end of the request. For example I can't afford
for php to just blow up in our account setup script, we are reaching out to
multiple non-transactional external resources. Some of our long running
command line processes have the same issue. I am all for type hinting but
the fatal errors or catchabale fatal errors are just silly. Exceptions
make so much more sense to me.
IMHO we shouldn't be getting to any kind of fatal error/exception
situation, which is why I like the idea of auto-conversion plus E_STRICT in
the 'weird conversion' scenarios (the API function shouldn't care - it got
what it asked for; The caller would get notified that he passed something
that probably doesn't make sense).
But as to why errors and not exceptions - we have a guideline that language
constructs don't through exceptions. It's up to users whether they want to
use exceptions or not.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm thinking about the type hinting in php for a while, and there is my 2
cent about this.
As an API developer, I need a way, to easily force my input into a proper
type, with ease, without dataloss, and without code duplication.
As an API consumer, I don't want to bother much about my API calls, as long
as my passed arguments are in the accepted form(I don't want to
convert '123' into 123), and I don't want to create yet another custom error
handler, to fetch the potentially triggered errors, and I cannot allow, that
one unhandled catcable fatal error ruin my application.
So basically I need type jugling(weak type hinting) + exceptions instead of
catchable errors.
But I know that the core should't throw exceptions, so we can't go to that
direction.
What if we introduce a new spl interface, which propose auto boxing for the
scalar types + exceptions for the type missmatch.
I mean, if you call that class with scalar arguments, the scalar values will
be converted to the matching spl class instance.
This way, you could hint your types for the interface without forcing the
api consumer to bother to convert '123' to 123 before passing it to the
method.
But if the consumer passes '123abc' when I'm hinting SplInt, then it will
throw an InvalidArgumentException or such.
So for example:
class foo implements WeakTypeHinting{
public function bar(SplInt $baz){
return $baz++;
}
}
$foo = new foo;
echo $foo-bar(1);
// 2
echo $foo-bar('2');
// 3
echo $foo-bar('3a')
// InvalidArgumentException
Feel free to discuss.
Tyrael
Re: [PHP-DEV] Type hinting
At 08:28 28/05/2010, Tjerk Anne Meesters wrote: On the other hand, auto-casting used to be my favourite until I glanced over the conversion table; it's not just regular casting, it has different rules. I wouldn't want to be the one going over that table when writing code against a certain API, I should only need to see the documentation. Tjerk, I think you have a nice idea about E_STRICT, except it makes much more sense with auto-conversion. That is - in case of 'fail' - we'd still convert, and emit E_STRICT (or E_NOTICE). That means that the API developer will always get the type he expects, while the user will be guided in the right direction in a friendly PHPish manner. The conversion table is up for discussion, BTW. If most people prefer that it's more similar to PHP's existing auto-conversion rules (that appears to be the case) we can certainly do that. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
On the other hand, auto-casting used to be my favourite until I
glanced over the conversion table; it's not just regular casting, it
has different rules. I wouldn't want to be the one going over that
table when writing code against a certain API, I should only need to
see the documentation.
Tjerk,
I think you have a nice idea about E_STRICT, except it makes much
more sense with auto-conversion. That is - in case of 'fail' - we'd
still convert, and emit E_STRICT (or E_NOTICE). That means that the
API developer will always get the type he expects, while the user
will be guided in the right direction in a friendly PHPish manner.
The conversion table is up for discussion, BTW. If most people
prefer that it's more similar to PHP's existing auto-conversion rules
(that appears to be the case) we can certainly do that.
Zeev
I'm not 100% sure I follow, Zeev. Are you suggesting:
foo (int $a) { }
foo(1); // Works, no message
foo(1); // Works, no message
foo(1a); // Emits E_STRICT or E_NOTICE and casts to a 1
foo(array(1)); // Fatal
I could get behind that. In fact it also suggests that we could (later?)
alter the normal casting rules so that if you do a lossy conversion you get a
notice/strict in any case. Something to chew on.
I like that idea, as the purely strict typing that's in HEAD right now I find
worse than having no scalar type checking at all.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
As man from userland, I totally agree with Larry. I see completely no sense
in raising error when a safe conversion can be done. And I don't like
current implementation at all. It is completely not-php-way.
2010/5/28 Larry Garfield la...@garfieldtech.com
On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
On the other hand, auto-casting used to be my favourite until I
glanced over the conversion table; it's not just regular casting, it
has different rules. I wouldn't want to be the one going over that
table when writing code against a certain API, I should only need to
see the documentation.
Tjerk,
I think you have a nice idea about E_STRICT, except it makes much
more sense with auto-conversion. That is - in case of 'fail' - we'd
still convert, and emit E_STRICT (or E_NOTICE). That means that the
API developer will always get the type he expects, while the user
will be guided in the right direction in a friendly PHPish manner.
The conversion table is up for discussion, BTW. If most people
prefer that it's more similar to PHP's existing auto-conversion rules
(that appears to be the case) we can certainly do that.
Zeev
I'm not 100% sure I follow, Zeev. Are you suggesting:
foo (int $a) { }
foo(1); // Works, no message
foo(1); // Works, no message
foo(1a); // Emits E_STRICT or E_NOTICE and casts to a 1
foo(array(1)); // Fatal
I could get behind that. In fact it also suggests that we could (later?)
alter the normal casting rules so that if you do a lossy conversion you get
a
notice/strict in any case. Something to chew on.
I like that idea, as the purely strict typing that's in HEAD right now I
find
worse than having no scalar type checking at all.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
С уважением,
Виктор
Re: [PHP-DEV] Type hinting
I'd say that I agree on this, I would like to see the conversion rules
cleaned up and made more clear. The idea of emitting e_warning or
e_strict on conversions with data loss throughout the language is very
appealing. Maybe we really need to do that so conversion rules and
type hinting rules to work the same?
2010/5/28 Larry Garfield la...@garfieldtech.com:
On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
On the other hand, auto-casting used to be my favourite until I
glanced over the conversion table; it's not just regular casting, it
has different rules. I wouldn't want to be the one going over that
table when writing code against a certain API, I should only need to
see the documentation.
Tjerk,
I think you have a nice idea about E_STRICT, except it makes much
more sense with auto-conversion. That is - in case of 'fail' - we'd
still convert, and emit E_STRICT (or E_NOTICE). That means that the
API developer will always get the type he expects, while the user
will be guided in the right direction in a friendly PHPish manner.
The conversion table is up for discussion, BTW. If most people
prefer that it's more similar to PHP's existing auto-conversion rules
(that appears to be the case) we can certainly do that.
Zeev
I'm not 100% sure I follow, Zeev. Are you suggesting:
foo (int $a) { }
foo(1); // Works, no message
foo(1); // Works, no message
foo(1a); // Emits E_STRICT or E_NOTICE and casts to a 1
foo(array(1)); // Fatal
I could get behind that. In fact it also suggests that we could (later?)
alter the normal casting rules so that if you do a lossy conversion you get a
notice/strict in any case. Something to chew on.
I like that idea, as the purely strict typing that's in HEAD right now I
find
worse than having no scalar type checking at all.
--Larry Garfield
--
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] Type hinting
On 28.05.2010, at 10:57, Arvids Godjuks wrote: I'd say that I agree on this, I would like to see the conversion rules cleaned up and made more clear. The idea of emitting e_warning or e_strict on conversions with data loss throughout the language is very appealing. Maybe we really need to do that so conversion rules and type hinting rules to work the same? Which conversion rules? the one in PHP today or the one in the weak type hinting RFC? In the weak type hinting RFC the conversion rules are pretty clear to me, anything that converts without data loss goes through, anything else does not convert silently (or even fails if we want to be so strict, depending on which approach we prefer). I personally prefer the cleaned up conversion rules from the RFC (and would love if we could figure out some way to do something similar for the entire type juggeling in PHP). However I can also accept if we simply stick with the same rules as PHP has atm (albeit still with the addition that a cast that causes data loss would not happen silently 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, Apparently, the discussion is not looking like it will end up in a general agreement. I'd suggest the following: 1) Since it seems that there is concerns about the current auto-casting RFC (inconsistencies, when/what errors, etc..), I believe it's authors should refine the RFC to propose what they want in a more precise way, unless what is available is exactly what they want, in which case they should state it. In my opinion, it should include: - The complete set of rules to apply - In case it is not like it is done internally, whether we should make it consistent (e.g. change the way arguments are passed to internal functions) - In which case an error is triggered, and what errors/exception - If the current hints of arrays/objects should be relaxed somehow (i.e. ArrayObject instance accepted for an array argument) 2) For strict typing, I believe it is clear about what it does. However, there is still room for discussion on: - Whether all types hints should be available (or, e.g. only numeric/scalar) - What errors/exception to trigger so, it would be nice to update the RFC(s), so that we have a solid ground on which we can discuss/vote. Best, On Fri, May 28, 2010 at 02:57, Philip Olson phi...@roshambo.org wrote: This thread needed post #100 so here goes: - We want both options, can we accept this and focus on making it happen? - I love using === but am okay with others ab^H^Husing == - The strict type hinting patch now includes 'numeric' and 'scalar' type hints Regards, Philip -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Fri, May 28, 2010 at 11:04, Lukas Kahwe Smith m...@pooteeweet.org wrote: In the weak type hinting RFC the conversion rules are pretty clear to me, anything that converts without data loss goes through, anything else does not convert silently (or even fails if we want to be so strict, depending on which approach we prefer). I personally prefer the cleaned up conversion rules from the RFC (and would love if we could figure out some way to do something similar for the entire type juggeling in PHP). However I can also accept if we simply stick with the same rules as PHP has atm (albeit still with the addition that a cast that causes data loss would not happen silently My biggest problem with the weak type hinting approach is the inconsistency with the current array type hint. Currently if you pass int(42) to an array type hint it will fail. For the weak type hint it will cast it to whatever was hinted. This is inconsistent with our current userland (array) casting, where (array)42 ends up being array(42); And same with passing an array(42) to a boolean hint, which with the (bool) cast returns bool(true). And what if I pass int(42) to boolean hint? Its an obvious dataloss, should that trigger a warning message or fail? The edgecases for the weak type hinting are way to many and inconsistent with the rest of our casting structure, so adding more inconsistencies by introducing other type of type hinting makes type hinting in general inconsistent with eachother - leading to even more pain. I want the strict type hinting because it is consistent with the current type hinting implementation, and I don't have to deal with any warnings or weirdness. I either get the exact data I wanted or it fails. I have other means of casting data, and I can pick myself how I cast it (with or without dataloss, with or without warnings). -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Lukas, Etienne, Hannes:
You all pointed out the issues and enhansments that can be done.
Basic thing I want to say that type hinting and data casting should be
done in tandem and work the same way. So generally there is a need to
rething how type casting works and implement enhansments with adding
type hints.
(int)42 = array(42) is a good point, it works now. With type hinting
it makes a catchable fatal error. So there is a question - make type
hints follow the cast rules, or cast rules should follow current type
hinting rules. Because although I don't see a problem in remembering
that $int = (int)123abc works fine and function a(int $int) {}
a(123abc); fails with an error. But some argue to the ground that it
should cast also, or implement a strict type hinting (witch in my
opinion isn't for PHP, it's not in its nature, and I want PHP to
evolve it's own way, not to become a twin for Ruby, Python, etc),
because they don't want to remember rules for the type hints (btw, if
you can code PHP, C# and Python, you should have quite good memory and
some additional easy rules to remember isn't such a big thing).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Am 27.05.2010 12:59, schrieb Ilia Alshanetsky:
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired outcome.
Which is why, for instance, PHPUnit today is full of code like this
public function foo($flag)
{
if (!is_bool($flag)) {
throw new InvalidArgumentException(/* ... */);
}
}
This is the type of code that I want to get rid off using scalar type
hints.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Am 27.05.2010 00:30, schrieb Derick Rethans:
Would it be possible to support two syntaxes:
function foo( (int) $bar) { } // auto-cast to int
function foo(int $bar) { } // require int
I think that's a brilliant plan. We won't ever agree on whether we want
either strict type hinting, or casting typehinting and this provides
both possibilities with the following pros:
- The syntax is consistent for casting. We already support (int) $bar
anywhere else.
- The syntax is consistent for strict type checking. We already support
throwing errors with foo(ClassName $bar).
- There are no new conversion rules that can confuse people.
- Type checking with int $bar will stay fast, as we only have to
compare type.
+1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! Currently if you pass int(42) to an array type hint it will fail. For the weak type hint it will cast it to whatever was hinted. This makes sense. 42 doesn't have array representation. We might introduce a rule that if anything passed to a function that requires array gets converted to one-element array, but that's our discretion, depending on use cases. This is inconsistent with our current userland (array) casting, where (array)42 ends up being array(42); Explicit casting may not be the same as implicit. In explicit casting the intent of the user is, well, explicit, so we can afford more drastic changes than in implicit case. And same with passing an array(42) to a boolean hint, which with the (bool) cast returns bool(true). And what if I pass int(42) to boolean hint? Its an obvious dataloss, should that trigger a warning message or fail? How it's a data loss? You want to know if it's boolean-ly true or false, not keep the whole int. It's like saying calling strlen is a data loss because of the whole string it keeps only length. That's exactly what you wanted it to do! The edgecases for the weak type hinting are way to many and inconsistent with the rest of our casting structure, so adding more That's not edge cases, that's just the cases where we have to define language behavior as it makes sense. Consistency for the sake of everything doing the same even if it makes no sense is bullshit. And so far the only case is arrays - which *are* different from scalars, so expecting that they work the same is baseless. Different types have different properties. I want the strict type hinting because it is consistent with the current type hinting implementation, and I don't have to deal with any Current implementation is for objects. Objects work differently from scalar types. Pretending they are the same for consistency makes absolutely zero sense. -- 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] Type hinting
Hi! I think that's a brilliant plan. We won't ever agree on whether we want either strict type hinting, or casting typehinting and this provides both possibilities with the following pros: For the record, I think having both is even worse than having one of them. That makes the language into mishmash of options which work similarly but different and make code harder to understand and harder to work with - imagine working with 5 libraries, 3 of which use one method and another 2 use another and you have to remember on each step which one uses which. -- 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] Type hinting
Hi!
Which is why, for instance, PHPUnit today is full of code like this
public function foo($flag)
{
if (!is_bool($flag)) {
throw new InvalidArgumentException(/* ... */);
}
}
This is the type of code that I want to get rid off using scalar type
hints.
The question here is does it make sense somewhere outside PHPUnit? I.e.
I can see why unit test cares if method returned false or or 0 -
because if you test for value false, you should get false. However,
outside the test realm, why would you case if you need to disable an
option and get 0 instead of false? Was it unclear what 0 meant? Is there
any problem with interpreting what user intended to do and doing it? Why
insist on having right zval bits?
--
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] Type hinting
Am 28.05.2010 19:45, schrieb Stas Malyshev: The question here is does it make sense somewhere outside PHPUnit? I have seen boilerplate [1] code like this in other Open Source projects as well as closed-source applications. -- [1] boilerplate as is code I need to write because the language lacks syntax support for optional type checking in the function/method signature -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! I have seen boilerplate [1] code like this in other Open Source projects as well as closed-source applications. I've seen all kinds of code, whether making sense or not. The question is not if somebody somewhere is doing it but if it's the right thing to recommend to do. I think that outside very limited areas (like unit tests, etc.) where actual zval types matter, it usually is not. I don't see how distinguishing 0 from false may make sense in this case, unless the method is something like assertFalse(). And in the latter case you probably want to handle it inside anyway since you've got to compose the nice error message :) On top of that, your boilerplate throws exception. Strict typing would error out. That's very different thing (exceptions can be handled hierarchically, errors can't). So replacing that with strict type probably won't do the same. -- 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] Type hinting
Just wanted to remind everyone that option #3 proposed earlier doesn't
include auto-casting when data loss is happening.
That means:
function hintMe(int $number) {
}
hintMe(1);
hintMe(1);
hintMe(1.0);
hintMe(array(1)); - Error or notice, no array - int conversions
hintMe(1.25); - Error or notice because data is lost.
hintMe(1 abc); - Error or notice because data is lost.
As I understood the author. So basically we are free of type juggling
in cases when strait forward conversion can be done. like 1 = 1
(int), 20.2 = 20.2 (float).
We receive a warning or a fatal error when we pass something that
can't be converted straight forward like 1.01 = 1 (int) or 1 abs =
1 (int), array(20) = 20.0 (float) and so on. The basic concept as I
understood is: Convert if there is no data loss, else give an error.
So please, stop discussing this, it really annoys to read the same
thing over and over again.
As I said earlier, I'm against strict type checking and there is a
good reason for that: As someone already mentioned, in PHP we are
dealing with strings 90% of the time - GET, POST, data from databases
or any other external source. We get integers and floats only when
stuff is initialized or calculated inside the script. For the external
data we rely on type auto conversion with some additional checks if
needed (I don't think you will ever check the field type when
selecting from database, because I know it's type in schema - you just
use it and rely on automatic conversion).
So really - can we stop arguing, polish the rules and get to the
implementation? :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi,
On Thu, May 27, 2010 at 09:45, Arvids Godjuks arvids.godj...@gmail.com wrote:
Just wanted to remind everyone that option #3 proposed earlier doesn't
include auto-casting when data loss is happening.
That means:
function hintMe(int $number) {
}
hintMe(1);
hintMe(1);
hintMe(1.0);
hintMe(array(1)); - Error or notice, no array - int conversions
hintMe(1.25); - Error or notice because data is lost.
hintMe(1 abc); - Error or notice because data is lost.
As I understood the author. So basically we are free of type juggling
in cases when strait forward conversion can be done. like 1 = 1
(int), 20.2 = 20.2 (float).
We receive a warning or a fatal error when we pass something that
can't be converted straight forward like 1.01 = 1 (int) or 1 abs =
1 (int), array(20) = 20.0 (float) and so on. The basic concept as I
understood is: Convert if there is no data loss, else give an error.
So please, stop discussing this, it really annoys to read the same
thing over and over again.
As I said earlier, I'm against strict type checking and there is a
good reason for that: As someone already mentioned, in PHP we are
dealing with strings 90% of the time - GET, POST, data from databases
or any other external source. We get integers and floats only when
stuff is initialized or calculated inside the script. For the external
data we rely on type auto conversion with some additional checks if
needed (I don't think you will ever check the field type when
selecting from database, because I know it's type in schema - you just
use it and rely on automatic conversion).
90% of your function calls are involving values with random scalar
types? really ?
Personally, I think it would be extremely bad code, but actually, I
doubt it's even true.
So really - can we stop arguing, polish the rules and get to the
implementation? :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function doSomeStuffWithDbData(int $id, string $name, int $someFlag) {
}
$sql = 'SELECT id, name, some_flag, FROM table WHERE .';
$res = mysqli_query($db, $sql);
$row = $res-fetch_assoc();
doSomeStuffWithDbData((int)$row['id'], $row['name'], (int)$row['some_flag']);
And so on. There is no meaning in doing explicit type casts and then
check the type again! Because if you have bogus data like 123abc
with type cast you cast it to 123 integer and you function check for
integer will pass without any notice!
Hm, it just strike me. If you want a strict type checks, you have to
convert your data before you pass it when it comes from outside (and
it always does by the way! - databases, request data, files). So
basically you will first convert it and then pass to functions to
avoid inconsistent type errors. And UPS! Magically you have no errors!
because $data = '123abc'; $data = (int)$data; results in pure 123 int.
No benefit in using type hints at all.
2010/5/27 Etienne Kneuss col...@php.net:
Hi,
On Thu, May 27, 2010 at 09:45, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Just wanted to remind everyone that option #3 proposed earlier doesn't
include auto-casting when data loss is happening.
That means:
function hintMe(int $number) {
}
hintMe(1);
hintMe(1);
hintMe(1.0);
hintMe(array(1)); - Error or notice, no array - int conversions
hintMe(1.25); - Error or notice because data is lost.
hintMe(1 abc); - Error or notice because data is lost.
As I understood the author. So basically we are free of type juggling
in cases when strait forward conversion can be done. like 1 = 1
(int), 20.2 = 20.2 (float).
We receive a warning or a fatal error when we pass something that
can't be converted straight forward like 1.01 = 1 (int) or 1 abs =
1 (int), array(20) = 20.0 (float) and so on. The basic concept as I
understood is: Convert if there is no data loss, else give an error.
So please, stop discussing this, it really annoys to read the same
thing over and over again.
As I said earlier, I'm against strict type checking and there is a
good reason for that: As someone already mentioned, in PHP we are
dealing with strings 90% of the time - GET, POST, data from databases
or any other external source. We get integers and floats only when
stuff is initialized or calculated inside the script. For the external
data we rely on type auto conversion with some additional checks if
needed (I don't think you will ever check the field type when
selecting from database, because I know it's type in schema - you just
use it and rely on automatic conversion).
90% of your function calls are involving values with random scalar
types? really ?
Personally, I think it would be extremely bad code, but actually, I
doubt it's even true.
So really - can we stop arguing, polish the rules and get to the
implementation? :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi, if it comes to auto-converting (that's different from existing type-juggling): wouldn't it be nice, to change type-juggling as well? I know about BC breaks here, thus it would need till PHP 7 or so to become the default behavior. But I think, BC breaks mainly occur in the cases where type-juggling is more hiding programming errors than helping the user - that is: where the developer should really care about checking and/or casting. As an advantage, hints and type-juggling would at least behave consistent, reducing complexity for the users (and perhaps internally for you as core developers as well). Am Donnerstag, 27. Mai 2010 07:42:32 schrieb Zeev Suraski: Can anybody share with us *common* cases where strict typing would be necessary, and the proposed auto-converting type hints won't do? If you use CouchDB as backend (where data is stored as JSON), there is a difference if you store 42 , 42, or 42.0. IIRC I read on the CouchDB mailing list that this can influence view sorting. (As I strictly care about types in my application, I didn't had problems yet.) Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, May 27, 2010 at 10:34, Arvids Godjuks arvids.godj...@gmail.com wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function doSomeStuffWithDbData(int $id, string $name, int $someFlag) {
}
$sql = 'SELECT id, name, some_flag, FROM table WHERE .';
$res = mysqli_query($db, $sql);
$row = $res-fetch_assoc();
doSomeStuffWithDbData((int)$row['id'], $row['name'], (int)$row['some_flag']);
And so on. There is no meaning in doing explicit type casts and then
check the type again! Because if you have bogus data like 123abc
with type cast you cast it to 123 integer and you function check for
integer will pass without any notice!
Hm, it just strike me. If you want a strict type checks, you have to
convert your data before you pass it when it comes from outside (and
it always does by the way! - databases, request data, files). So
basically you will first convert it and then pass to functions to
avoid inconsistent type errors. And UPS! Magically you have no errors!
because $data = '123abc'; $data = (int)$data; results in pure 123 int.
No benefit in using type hints at all.
If you don't know whether the user/database provided information you
have is correct before you pass it along to something else, I would
say that the code indeed is bad. Unless you regard 123abc as a valid
value from your user, don't allow the user to give you that value. If
you regard it as a valid value, then it's not an int thus you wouldn't
want to type cast it in the first place.
--
Daniel Egeberg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Heh... Please do a DB select and make a var_dump on the rows from
database. You will see things like:
array(3) {
[id]=
string(1) 1
[ref_id]=
string(2) 15
[name]=
string(7) Bla bla
}
string, string and string again.
And that breaks the concept of strict type hinting. Because we get
data from DB in STRING type, regardless of the type of the DB fields.
And that's my argument for auto-converting type hints when it is
possible without data loss. I expect PHP to pass indexes id and
ref_id to function, witch expects int without any notices or errors
- just do the bloody thing with converting to int and do your work. If
I pass name index to that function - it should fail with a Fatal
error.
So, stop twisting my words and taking sentences out of the context,
please! I don't want to argue on things that I described in detail and
people just skim them trough just to reply with critics just for the
sake of making a reply.
2010/5/27 Daniel Egeberg daniel.egeb...@gmail.com:
On Thu, May 27, 2010 at 10:34, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function doSomeStuffWithDbData(int $id, string $name, int $someFlag) {
}
$sql = 'SELECT id, name, some_flag, FROM table WHERE .';
$res = mysqli_query($db, $sql);
$row = $res-fetch_assoc();
doSomeStuffWithDbData((int)$row['id'], $row['name'], (int)$row['some_flag']);
And so on. There is no meaning in doing explicit type casts and then
check the type again! Because if you have bogus data like 123abc
with type cast you cast it to 123 integer and you function check for
integer will pass without any notice!
Hm, it just strike me. If you want a strict type checks, you have to
convert your data before you pass it when it comes from outside (and
it always does by the way! - databases, request data, files). So
basically you will first convert it and then pass to functions to
avoid inconsistent type errors. And UPS! Magically you have no errors!
because $data = '123abc'; $data = (int)$data; results in pure 123 int.
No benefit in using type hints at all.
If you don't know whether the user/database provided information you
have is correct before you pass it along to something else, I would
say that the code indeed is bad. Unless you regard 123abc as a valid
value from your user, don't allow the user to give you that value. If
you regard it as a valid value, then it's not an int thus you wouldn't
want to type cast it in the first place.
--
Daniel Egeberg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 27.05.2010, at 10:45, Daniel Egeberg wrote: If you don't know whether the user/database provided information you have is correct before you pass it along to something else, I would say that the code indeed is bad. Unless you regard 123abc as a valid value from your user, don't allow the user to give you that value. If you regard it as a valid value, then it's not an int thus you wouldn't want to type cast it in the first place. as Arvids already pointed out most database extensions for PHP atm return strings even for integers/floats. furthermore the 123abc example was mentioned more for data coming from external sources, with strict typing you are encouraging stuff like (int)123abc. Of course a good programmer would first check with is_numeric() before casting. Seems like a lot of work. With the proposal of weak typing with error/notice on data loss none of that would be needed. 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 .
I think there is no need to argue on it any more.
Good programmers have the ability to manipulate the variables' types.
But I think it's the icing on the cake if we give the PHP programmer the choice
of whether use explicit types.
For examlpe, we may add a switch in php.ini, let's say, explict_types=On/Off.
- Original Message -
From: Daniel Egeberg daniel.egeb...@gmail.com
To: Arvids Godjuks arvids.godj...@gmail.com
Cc: Etienne Kneuss col...@php.net; PHP internals internals@lists.php.net
Sent: Thursday, May 27, 2010 4:45 PM
Subject: Re: [PHP-DEV] Type hinting
On Thu, May 27, 2010 at 10:34, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function doSomeStuffWithDbData(int $id, string $name, int $someFlag) {
}
$sql = 'SELECT id, name, some_flag, FROM table WHERE .';
$res = mysqli_query($db, $sql);
$row = $res-fetch_assoc();
doSomeStuffWithDbData((int)$row['id'], $row['name'], (int)$row['some_flag']);
And so on. There is no meaning in doing explicit type casts and then
check the type again! Because if you have bogus data like 123abc
with type cast you cast it to 123 integer and you function check for
integer will pass without any notice!
Hm, it just strike me. If you want a strict type checks, you have to
convert your data before you pass it when it comes from outside (and
it always does by the way! - databases, request data, files). So
basically you will first convert it and then pass to functions to
avoid inconsistent type errors. And UPS! Magically you have no errors!
because $data = '123abc'; $data = (int)$data; results in pure 123 int.
No benefit in using type hints at all.
If you don't know whether the user/database provided information you
have is correct before you pass it along to something else, I would
say that the code indeed is bad. Unless you regard 123abc as a valid
value from your user, don't allow the user to give you that value. If
you regard it as a valid value, then it's not an int thus you wouldn't
want to type cast it in the first place.
--
Daniel Egeberg
--
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] Type hinting
Exactly. Yes, we check data coming from POST/GET/COOKIE and other really external resources. But doing the same for data coming from database is kinda an overkill. And most projects do select their data mostly from databases. And I'm 100% sure that people will not use type hinting if they have to do all the conversions in the code just so that data coming from DB doesn't trigger errors on type hinting checks. Brr, that's just tons of code to add - convert every int/fload/decimal field to int/float in PHP. 2010/5/27 Lukas Kahwe Smith m...@pooteeweet.org: On 27.05.2010, at 10:45, Daniel Egeberg wrote: If you don't know whether the user/database provided information you have is correct before you pass it along to something else, I would say that the code indeed is bad. Unless you regard 123abc as a valid value from your user, don't allow the user to give you that value. If you regard it as a valid value, then it's not an int thus you wouldn't want to type cast it in the first place. as Arvids already pointed out most database extensions for PHP atm return strings even for integers/floats. furthermore the 123abc example was mentioned more for data coming from external sources, with strict typing you are encouraging stuff like (int)123abc. Of course a good programmer would first check with is_numeric() before casting. Seems like a lot of work. With the proposal of weak typing with error/notice on data loss none of that would be needed. 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
On Thu, May 27, 2010 at 10:53, Arvids Godjuks arvids.godj...@gmail.com wrote:
Heh... Please do a DB select and make a var_dump on the rows from
database. You will see things like:
array(3) {
[id]=
string(1) 1
[ref_id]=
string(2) 15
[name]=
string(7) Bla bla
}
string, string and string again.
And that breaks the concept of strict type hinting. Because we get
data from DB in STRING type, regardless of the type of the DB fields.
And that's my argument for auto-converting type hints when it is
possible without data loss. I expect PHP to pass indexes id and
ref_id to function, witch expects int without any notices or errors
- just do the bloody thing with converting to int and do your work. If
I pass name index to that function - it should fail with a Fatal
error.
So, stop twisting my words and taking sentences out of the context,
please! I don't want to argue on things that I described in detail and
people just skim them trough just to reply with critics just for the
sake of making a reply.
I don't see how I'm twisting your words.
As for the database: Hopefully you know what types you have in your
database. If you know that a particular column is an int, then casting
to int is entirely a non-issue.
As for user provided data: Say you ask the user how old he is (that
would be an int)? If he answers 123abc then your validation logic
should catch that he entered an invalid value. Once you've determined
that it is a valid value, then casting to int is a non-issue.
--
Daniel Egeberg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
No .ini switches. Forget it. Developers of PHP said it clearly - NO
.ini values that change the behaviour of PHP! Ever! Topic closed.
2010/5/27 魏世江 shiji...@staff.sina.com.cn:
Hi .
I think there is no need to argue on it any more.
Good programmers have the ability to manipulate the variables' types.
But I think it's the icing on the cake if we give the PHP programmer the
choice of whether use explicit types.
For examlpe, we may add a switch in php.ini, let's say, explict_types=On/Off.
- Original Message -
From: Daniel Egeberg daniel.egeb...@gmail.com
To: Arvids Godjuks arvids.godj...@gmail.com
Cc: Etienne Kneuss col...@php.net; PHP internals
internals@lists.php.net
Sent: Thursday, May 27, 2010 4:45 PM
Subject: Re: [PHP-DEV] Type hinting
On Thu, May 27, 2010 at 10:34, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function doSomeStuffWithDbData(int $id, string $name, int $someFlag) {
}
$sql = 'SELECT id, name, some_flag, FROM table WHERE .';
$res = mysqli_query($db, $sql);
$row = $res-fetch_assoc();
doSomeStuffWithDbData((int)$row['id'], $row['name'],
(int)$row['some_flag']);
And so on. There is no meaning in doing explicit type casts and then
check the type again! Because if you have bogus data like 123abc
with type cast you cast it to 123 integer and you function check for
integer will pass without any notice!
Hm, it just strike me. If you want a strict type checks, you have to
convert your data before you pass it when it comes from outside (and
it always does by the way! - databases, request data, files). So
basically you will first convert it and then pass to functions to
avoid inconsistent type errors. And UPS! Magically you have no errors!
because $data = '123abc'; $data = (int)$data; results in pure 123 int.
No benefit in using type hints at all.
If you don't know whether the user/database provided information you
have is correct before you pass it along to something else, I would
say that the code indeed is bad. Unless you regard 123abc as a valid
value from your user, don't allow the user to give you that value. If
you regard it as a valid value, then it's not an int thus you wouldn't
want to type cast it in the first place.
--
Daniel Egeberg
--
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] Type hinting
On Thu, May 27, 2010 at 11:05, 魏世江 shiji...@staff.sina.com.cn wrote: Hi . I think there is no need to argue on it any more. Good programmers have the ability to manipulate the variables' types. But I think it's the icing on the cake if we give the PHP programmer the choice of whether use explicit types. For examlpe, we may add a switch in php.ini, let's say, explict_types=On/Off. A php.ini setting is a really bad idea. Say that Library A expects it to be On, but Library B expects it to be Off. Now what happens if I want to use *both* Library A and Library B? -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 27.05.2010, at 11:05, 魏世江 wrote: But I think it's the icing on the cake if we give the PHP programmer the choice of whether use explicit types. For examlpe, we may add a switch in php.ini, let's say, explict_types=On/Off. heh .. you are giving the question cake or death a new dimension :) seriously php.ini settings to manipulate how core syntax is interpreted are a no no. 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
Lest not touch the validation topic - it's obvious and we are not
talking about it.
As for the DB - I don't want to write code like this.
// Select from DB
// Start the loop fetch the data
settype('integer', $row['id']);
settype('float', $row['price']);
settype('int', $row['amount']);
settype('integer', $row['order_id']);
//
// End of loop here
// Do the data processing
Sorry, but that's just stupid code.
2010/5/27 Daniel Egeberg daniel.egeb...@gmail.com:
On Thu, May 27, 2010 at 10:53, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Heh... Please do a DB select and make a var_dump on the rows from
database. You will see things like:
array(3) {
[id]=
string(1) 1
[ref_id]=
string(2) 15
[name]=
string(7) Bla bla
}
string, string and string again.
And that breaks the concept of strict type hinting. Because we get
data from DB in STRING type, regardless of the type of the DB fields.
And that's my argument for auto-converting type hints when it is
possible without data loss. I expect PHP to pass indexes id and
ref_id to function, witch expects int without any notices or errors
- just do the bloody thing with converting to int and do your work. If
I pass name index to that function - it should fail with a Fatal
error.
So, stop twisting my words and taking sentences out of the context,
please! I don't want to argue on things that I described in detail and
people just skim them trough just to reply with critics just for the
sake of making a reply.
I don't see how I'm twisting your words.
As for the database: Hopefully you know what types you have in your
database. If you know that a particular column is an int, then casting
to int is entirely a non-issue.
As for user provided data: Say you ask the user how old he is (that
would be an int)? If he answers 123abc then your validation logic
should catch that he entered an invalid value. Once you've determined
that it is a valid value, then casting to int is a non-issue.
--
Daniel Egeberg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired outcome.
On Thu, May 27, 2010 at 1:42 AM, Zeev Suraski z...@zend.com wrote:
At 00:28 27/05/2010, Davey Shafik wrote:
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
as:
function foo($bar) {
if (!is_int($bar)) {
// error
}
}
Why bother with either if that's the case?
I don't think there's any argument that what we're proposing to add to the
language can already be done using existing functionality. That's true
whether we're talking about strict type checking, auto-converting type
hinting, or pretty much any other idea we might come up with.
There are several reasons we still want to add this feature - reducing the
burden of validating input, making it clearer to the user what the function
expects (from the API), and in the future - it might allow for certain
optimizations.
When we come to evaluate which solution we should pick, we should go for
the solution that is the most consistent with the rest of the language and
that gives us the most bang for the buck. Auto-converting type hinting
falls in that category - it's the most consistent with the rest of the
language, and it's the most useful behavior in the vast majority of cases -
it stands a chance to become widely used. For every case where you'd
explicitly care about the zval.type (such as when you need to differentiate
between false and zero), you'd have dozens of cases where you won't. Adding
language level support for those rare cases simply doesn't make sense. The
marginal gain is minimal. The added complexity and confusion is very high.
I'm strictly against having two solutions. It's the worst outcome we could
reach IMHO - it means we're unable to decide which is better, so we support
both (kind of like a hi-tech version of http://bit.ly/9I8dHw). I think
it's the one solution that's worse than implementing strict typing only - it
does mean that I would actually support having strict typing only over
having both. Still, I think having auto-converting type hints is by far the
best solution.
Can anybody share with us *common* cases where strict typing would be
necessary, and the proposed auto-converting type hints won't do?
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Brian, What we are talking about here is an **optional** feature for user-land function that allow the author to implement really cheap input-validation to facilitate ensuring that the correct input is supplied. Additionally it also allows for better language interrogation for auto-generation of things like SOAP WSDL and alike. On Wed, May 26, 2010 at 6:02 PM, Brian Moon br...@moonspot.net wrote: I like the idea of type hinting a lot. (See: http://marc.info/?l=zend-engine2m=102421231114377w=2) I suggested it in 2001 when ZE2 was being designed. Somehow my idea was bastardized into only classes and arrays. Guess it was the mad OOP craze of the time. Anyhow, I would like to use it. And, as much as I appreciate Derick and Ilia's work in getting a change in, I likely won't use it. Mainly because the web is a bunch of strings. Casting data from MySQL every time I want to use it does not interest me at all. Its a number in string form, treat it like one. If you use filter, you still have to worry with casting. There is no way to always get an int back from filter regardless of the input given. Really, I am confused what the argument is about. We already decided how this should work years ago. It should work just like the code below. Having user land functions work different than built in functions is the most confusing thing you can do. Unless of course someone plans on fixing all the internal functions too. ?php error_reporting(E_ALL); $int = 1.25454; $var = substr($int, 0, 4); var_dump($var); $var = round($var, 1); var_dump($var); $arr = array(); $var = substr($arr, 0, 1); var_dump($var); $text = test; $var = round($text, 1); var_dump($var); ? $ php test.php string(4) 1.25 float(1.3) Warning: substr() expects parameter 1 to be string, array given in /Users/brianm/test.php on line 17 NULL float(0) Brian. brianlm...@php.net http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Why not do the check and let auto converting for int = float, int =
string, string = int, string = float when it doesn't loose any
precision.
2010/5/27 Ilia Alshanetsky i...@prohost.org:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired outcome.
On Thu, May 27, 2010 at 1:42 AM, Zeev Suraski z...@zend.com wrote:
At 00:28 27/05/2010, Davey Shafik wrote:
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
as:
function foo($bar) {
if (!is_int($bar)) {
// error
}
}
Why bother with either if that's the case?
I don't think there's any argument that what we're proposing to add to the
language can already be done using existing functionality. That's true
whether we're talking about strict type checking, auto-converting type
hinting, or pretty much any other idea we might come up with.
There are several reasons we still want to add this feature - reducing the
burden of validating input, making it clearer to the user what the function
expects (from the API), and in the future - it might allow for certain
optimizations.
When we come to evaluate which solution we should pick, we should go for
the solution that is the most consistent with the rest of the language and
that gives us the most bang for the buck. Auto-converting type hinting
falls in that category - it's the most consistent with the rest of the
language, and it's the most useful behavior in the vast majority of cases -
it stands a chance to become widely used. For every case where you'd
explicitly care about the zval.type (such as when you need to differentiate
between false and zero), you'd have dozens of cases where you won't. Adding
language level support for those rare cases simply doesn't make sense. The
marginal gain is minimal. The added complexity and confusion is very high.
I'm strictly against having two solutions. It's the worst outcome we could
reach IMHO - it means we're unable to decide which is better, so we support
both (kind of like a hi-tech version of http://bit.ly/9I8dHw). I think
it's the one solution that's worse than implementing strict typing only - it
does mean that I would actually support having strict typing only over
having both. Still, I think having auto-converting type hints is by far the
best solution.
Can anybody share with us *common* cases where strict typing would be
necessary, and the proposed auto-converting type hints won't do?
Zeev
--
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] Type hinting
On 27.05.2010, at 12:59, Ilia Alshanetsky wrote: Zeev, Auto-conversion does not validate input to the function/method, it merely obfuscates the wrong input by converting it to desired type resulting in a potentially un-expected value. I must say I am completely against the auto-conversion hint idea. the current proposal is quote the opposite from obfuscation since it would alert the user if the conversion would imply data loss. 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
Because auto-conversion is magic and like any magic causes in-consistent
behaviour and what I like to call WTF factor, which means the developer is
not quite certain what is going on. With strict type hints the behaviour is
consistent every-time and there is no ambiguity of function.
On Thu, May 27, 2010 at 7:03 AM, Arvids Godjuks arvids.godj...@gmail.comwrote:
Why not do the check and let auto converting for int = float, int =
string, string = int, string = float when it doesn't loose any
precision.
2010/5/27 Ilia Alshanetsky i...@prohost.org:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting
in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
As far as your example goes consider a function that expects a boolean,
but
instead gets an int/string/float, which in nearly all cases will result
in
TRUE. Which is not the desired outcome.
On Thu, May 27, 2010 at 1:42 AM, Zeev Suraski z...@zend.com wrote:
At 00:28 27/05/2010, Davey Shafik wrote:
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
as:
function foo($bar) {
if (!is_int($bar)) {
// error
}
}
Why bother with either if that's the case?
I don't think there's any argument that what we're proposing to add to
the
language can already be done using existing functionality. That's true
whether we're talking about strict type checking, auto-converting type
hinting, or pretty much any other idea we might come up with.
There are several reasons we still want to add this feature - reducing
the
burden of validating input, making it clearer to the user what the
function
expects (from the API), and in the future - it might allow for certain
optimizations.
When we come to evaluate which solution we should pick, we should go for
the solution that is the most consistent with the rest of the language
and
that gives us the most bang for the buck. Auto-converting type hinting
falls in that category - it's the most consistent with the rest of the
language, and it's the most useful behavior in the vast majority of
cases -
it stands a chance to become widely used. For every case where you'd
explicitly care about the zval.type (such as when you need to
differentiate
between false and zero), you'd have dozens of cases where you won't.
Adding
language level support for those rare cases simply doesn't make sense.
The
marginal gain is minimal. The added complexity and confusion is very
high.
I'm strictly against having two solutions. It's the worst outcome we
could
reach IMHO - it means we're unable to decide which is better, so we
support
both (kind of like a hi-tech version of http://bit.ly/9I8dHw). I think
it's the one solution that's worse than implementing strict typing only
- it
does mean that I would actually support having strict typing only over
having both. Still, I think having auto-converting type hints is by far
the
best solution.
Can anybody share with us *common* cases where strict typing would be
necessary, and the proposed auto-converting type hints won't do?
Zeev
--
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] Type hinting
At 13:59 27/05/2010, Ilia Alshanetsky wrote: Zeev, Auto-conversion does not validate input to the function/method, it merely obfuscates the wrong input by converting it to desired type resulting in a potentially un-expected value. I must say I am completely against the auto-conversion hint idea. All of PHP is built on that kind of conversion. See Brian Moon's email for a detailed instructions. BTW - even if strict type checking was implemented, do you truly think people won't simply cast their inputs to make PHP shutup about 42 not being a valid int? Let me assure you, they would. You'd gain nothing - as a matter of fact you'd lose out a bit since abc strings or arrays will happily cast into (int), while with our proposed solution - they won't. As far as your example goes consider a function that expects a boolean, but instead gets an int/string/float, which in nearly all cases will result in TRUE. Which is not the desired outcome. Again, I don't think you can hope for anybody doing anything but (bool) cast before calling the function. And anyway, how is that different from if ($foo)? or while($bar)? Why would functions arguments behave any differently? If you care explicitly about zval.type being boolean, use is_bool(). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
At 14:09 27/05/2010, Ilia Alshanetsky wrote: Because auto-conversion is magic and like any magic causes in-consistent behaviour and what I like to call WTF factor, which means the developer is not quite certain what is going on. With strict type hints the behaviour is consistent every-time and there is no ambiguity of function. PHP is a lot about magic, about the thing the language does for you that you don't have to worry about. Memory management, type juggling, letting your overload function calling and property lookup, etc. - all fall in that category. There'll be clear rules as to how type hints would work - it's not as if there'd be a random element to it. Are you also against __toString()? That's magical at exactly the same level. You can view PHP's scalars as data types that have __toString(), __toInt(), etc. It's exactly the same. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, 2010-05-27 at 06:59 -0400, Ilia Alshanetsky wrote:
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired outcome.
Especially the int to boolean conversion is a really useful one in many
cases, in my opinion. Often enough one uses integers as as flags. For
instance with bit operations.
I consider
function do_something(bool $report_error) {
/* ... */
}
do_something(error_reporting() E_NOTICE);
absolutely legitimate.
And I think that it will hurt quite a bit if we force our users to take
care of their types. Usually a user doesn't have to care about the fact
that most databases return strings for all returned data. The database
ensures it's a numeric value in a specific range (that's why they are
using relational databases...) and that's all most users care about.
It's numeric and can be printed as string. Enforcing this can have quite
strange results users might not think about:
PDO_mysql allows an emulation of prepared statements. If that emulation
is being used all data will be returned as strings. Now people can turn
of this emulation and use native prepared statements. In that case the
data coming from MySQL's binary protocol will be put in properly typed
zvals. Now assume a library is using PDO with native prepared statements
and places type hints everywhere. At some point in time a user decides
that the additional roundtrip hurts and turns on emulation. Suddenly all
code will break. Fun.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 2010-05-27, at 8:14 PM, Zeev Suraski wrote:
At 13:59 27/05/2010, Ilia Alshanetsky wrote:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
All of PHP is built on that kind of conversion. See Brian Moon's email for a
detailed instructions.
BTW - even if strict type checking was implemented, do you truly think people
won't simply cast their inputs to make PHP shutup about 42 not being a
valid int? Let me assure you, they would. You'd gain nothing - as a matter
of fact you'd lose out a bit since abc strings or arrays will happily cast
into (int), while with our proposed solution - they won't.
Is a 'scalar' typehint still being considered? It doesn't seem to suffer from
the conversion vs. typechecking argument.
As far as this discussion goes, I would want to add the following:
function f(array $a) {
}
f(1234);
f(new StdClass);
Currently both throw:
Catchable fatal error: Argument 1 passed to f() must be an array, integer
given
IMHO it would be inconsistent with the language to let an 'int' typehint behave
in any way different.
The way I see it, one end of the discussion proposes:
function f(int $i) {
}
as an alternative to:
function f($i) {
$i = (int)$i;
}
While the other end as an alternative to:
function f($i) {
if (!is_int($i)) trigger_error(..etc..);
}
The first mainly just saves a few characters, (or introduces a whole new type
conversion table), while the second provides
* a consistent way to communicate incorrectly typed arguments.
* strict argument passing, making it easier to spot mistakes earlier in the
development process.
While you can disagree the world needs strict typing in PHP, I find it hard to
believe the 'conversion syntax sugar' is really considered.
Evert
P.S.: The last thing I want is add more noise to the discussion. Consider
emailing me off-list if you want to respond to this.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Is a 'scalar' typehint still being considered? It doesn't seem to suffer from the conversion vs. typechecking argument. Currently, it's available in trunk: http://svn.php.net/viewvc?view=revisionrevision=299707 Ah that's great news, thanks! Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, 27 May 2010, Johannes Schlüter wrote: On Thu, 2010-05-27 at 06:59 -0400, Ilia Alshanetsky wrote: As far as your example goes consider a function that expects a boolean, but instead gets an int/string/float, which in nearly all cases will result in TRUE. Which is not the desired outcome. And I think that it will hurt quite a bit if we force our users to take care of their types. *We* don't force anybody. API developers *could potentionally* force their consumers to take care about their types. regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
