Hi, Lazare Sorry, I've only looked at your first array-example :)
Bye Simon 2012/3/5 Lazare Inepologlou <linep...@gmail.com> > In your examples you are accessing an maybe non-existing array-key > > > Yes, this is why I used the error silencing (@) operator. But anyway, it > is irrelevant to the whole proposal. > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > > 2012/3/5 Simon Schick <simonsimc...@googlemail.com> > >> Hi, Lazare >> >> In your examples you are accessing an maybe non-existing array-key. >> This will raise an E_NOTICE. See the note below this example: >> http://php.net/manual/en/language.types.array.php#example-85 >> >> Maybe you also want something like that: >> isset($x) ? (is_null($x) ? null : (int)$x) : null >> >> But let's discuss that in a different thread. >> >> Bye >> Simon >> >> 2012/3/5 Lazare Inepologlou <linep...@gmail.com> >> >>> Anthony, >>> >>> I still don't like the null-as-a-default-value solution. I find it >>> confusing. >>> >>> I know that something similar appears in class type hinting, but: >>> 1. Class type hinting does not do casting (yet). >>> 2. Apart from null, no other value could be placed anyway. (Even that is >>> a >>> little bit wrong as null belongs to a different type than the hinted >>> class). >>> >>> ------- >>> >>> I have a different proposal. The argument type hinting/casting should not >>> be bothered with that at all. Instead, we could expand the type juggling >>> system a little bit, with the introduction of a special type of casting >>> that leaves null unchanged. Something like this: >>> >>> (int?) $x >>> >>> which should be strictly translated to the following, without any way to >>> change that behavior by any type casting overload system: >>> >>> is_null($x) ? null : (int)$x >>> >>> Examples: >>> >>> (int?) 13 // 13 >>> (int?) '' // 0 >>> (int?) 0 // 0 >>> (int?) null // null >>> (int?) '342.3Test' // 342 >>> >>> I can think of many real world scenarios that could benefit from this. >>> The >>> first that comes to my mind is reading from a database, in cases that the >>> value of null totally different than the value of 0. >>> >>> $parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different >>> things >>> here... >>> >>> A second example is reading from the query string: >>> >>> $id = (int?) @$_GET['id']; // the error-silencing operator will return >>> null on error. >>> >>> >>> Thoughts? >>> >>> >>> Lazare INEPOLOGLOU >>> Ingénieur Logiciel >>> >>> >>> 2012/3/5 Anthony Ferrara <ircmax...@gmail.com> >>> >>> > Matthew, >>> > >>> > Have you seen the new thread and RFC around this? >>> > https://wiki.php.net/rfc/parameter_type_casting_hints >>> > >>> > I went with option A, as I see erroring on cast as a more general >>> > problem. So for consistency, I implemented it exactly like normal >>> > explicit casts... >>> > >>> > Anthony >>> > >>> > On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney >>> > <weierophin...@php.net> wrote: >>> > > On 2012-03-02, Anthony Ferrara <ircmax...@gmail.com> wrote: >>> > >> Well, there are a few questions about the implementation: >>> > >> >>> > >> 1. *Which* type casting rules should it follow? >>> > >> >>> > >> a. Regular cast rules (like $foo = (int) $foo), where it converts >>> > >> always without error? >>> > >> b. Internal function cast rules, where it warnings on error and >>> > >> prevents execution of the function. >>> > >> c. Current type hinting rules, where if it can't convert cleanly it >>> > >> E_RECOVERABLE_ERRORS >>> > >> >>> > >> Personally, I like C the best. Where if it is passed an invalid >>> > >> value, it attempts to cleanly convert, but errors out if it can't... >>> > >> But I can see other arguments being made... >>> > > >>> > > (c) seems the most sane option ot me as well. >>> > > >>> > >> 2. Should (array) be supported? Perhaps. So at that point, >>> foo(array >>> > >> $bar) would do a "strict" check, and foo((array) $bar) would attempt >>> > >> to cast. But my question would be: what would attempt to cast mean? >>> > >> Should it error out if you pass foo(1)? That's what the internal >>> > >> function cast rules do. And to me that's more obvious than silently >>> > >> converting it to foo(array(1))... >>> > > >>> > > Turn this around and look at it from the current state of PHP: >>> > > >>> > > function foo($bar) >>> > > { >>> > > $bar = (array) $bar; >>> > > } >>> > > >>> > > If you pass a value of 1 for $bar, $bar is then converted to >>> array(1). >>> > > That's what I'd expect the following to do as well: >>> > > >>> > > function foo((array) $bar) >>> > > { >>> > > } >>> > > >>> > > It's casting, and clearly different than: >>> > > >>> > > function foo(array $bar) >>> > > { >>> > > } >>> > > >>> > > which is doing a typehint check. >>> > > >>> > >> 3. Should references be supported? My feeling is yes, they should. >>> > >> So if you do foo((array) &$bar), it would cast the original value >>> (if >>> > >> possible) as well. >>> > > >>> > > I personally would expect casting and references to be mutually >>> > > exclusive -- if you're casting, you're changing the value type, and I >>> > > wouldn't expect a destructive operation like this from passing a >>> value >>> > > to a function/method call. >>> > > >>> > > <snip> >>> > > >>> > >> 5. What about BC breaks? Well, this entire patch (up to this point) >>> > >> wouldn't require one. it's only adding the casting functionality >>> > >> (which is not implemented today), so no problem. Existing code >>> would >>> > >> still function fine. >>> > > >>> > > This is something that should be highlighted. I've seen a lot of >>> folks >>> > > claiming type hinting is viral, and the arguments make no sense to >>> me. >>> > > What your patch is offering is _opt_in_ type casting of >>> function/method >>> > > arguments. You don't _have_ to write your functions or methods using >>> > > them, and for those who do, it should have no side effects on code >>> > > calling it. >>> > > >>> > > I would _LOVE_ to see this as part of PHP. >>> > > >>> > > -- >>> > > Matthew Weier O'Phinney >>> > > Project Lead | matt...@zend.com >>> > > Zend Framework | http://framework.zend.com/ >>> > > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc >>> > > >>> > > -- >>> > > 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 >>> > >>> > >>> >> >> >
