Hello,

On Tue, Jan 12, 2010 at 11:40 PM, Chris Stockton
<chrisstockto...@gmail.com> wrote:
> Hello,
>
> On Mon, Jan 11, 2010 at 8:32 PM, mm w <0xcafef...@gmail.com> wrote:
>> cast is not needed in PHP
>>
>> i 'd rather be more interesting in
>>
>> class Obj {
>>     function __catch($data, $type) {
>>            //$type [ static_method, method, get_property, set_property]
>>            if (observed &&  $type == set_property && somevalueIsObserved) {
>>                  $observer->notify("somevalue::valueWillChanged");
>>                  $this->somevalue = $data['somevalue'];
>>                  $observer->notify("somevalue::valueDidChanged");
>>            } else {
>>                  continue__call();
>>            }
>>     }
>> }
>
> What? ...
>
>>> Etienne Kneuss wrote:
>>> This is where operator over-loading would be useful however perhaps only
>>> explicit casts would make sense here.
>
> I beleive adding a __cast(string $type) would be a useful feature for
> me, very often I have a toArray method defined. I agree with you that
> due to unexpected edge cases with operator precedence and general type
> juggling that __cast should only be called on explicit (cast).
>
> I.E.:
> class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; } 
> }
> $r = new Int;

This is an exemple where __cast would be very wrong. At the very
least, it should return a value that is an inhabitant of the requested
type! Do you really want (bool)new Int() to be Int 0?

as a result, you have three solutions:
1) have the engine issue an error in case the return value is not compatible
2) provide a return value for every possible types requested
3) throw an exception in case the cast is not handled

In the end, it looks way more complicated/magic than _simply_ defining
a toArray method that is used whenever you need an object to be an
array. You need an explicit cast anyway, so it's (array)$obj vs
$obj->toArray().

>
> var_dump($r + 1); // 2
> var_dump((int) $r + 1); // 16
> var_dump((bool) $r + 1); // 1
>
> --
> 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

Reply via email to