Hi, Lazare
Sorry, I've only looked at your first array-example :)
Bye
Simon
2012/3/5 Lazare Inepologlou <[email protected]>
> 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 <[email protected]>
>
>> 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 <[email protected]>
>>
>>> 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 <[email protected]>
>>>
>>> > 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
>>> > <[email protected]> wrote:
>>> > > On 2012-03-02, Anthony Ferrara <[email protected]> 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 | [email protected]
>>> > > 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
>>> >
>>> >
>>>
>>
>>
>