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();
}
}
}
On Mon, Jan 11, 2010 at 7:17 PM, Clint Priest <cpri...@warpmail.net> wrote:
>
> Etienne Kneuss wrote:
>>
>> Hello,
>>
>> On Mon, Jan 11, 2010 at 7:31 PM, Clint Priest <cpri...@warpmail.net>
>> wrote:
>>>
>>> I know there's been requests to add a __toArray() and most of the
>>> arguments
>>> against it is that there are too many magic functions already. I just
>>> thought I'd propose an alternative that would satisfy all of them.
>>>
>>> Why not a __cast($Type) magic function?
>>
>> I'd advance two reasons against this idea:
>>
>> 1) It's more self-explanatory to explicitly call the appropriate
>> converting method, enough with implicit madness!
>>
>> 2) For some operations, you'd have to know the types in advance before
>> knowing what operations needs to be performed:
>>
>> $obj1 + 2;
>>
>> Now what __cast should be called? Int? Float?
>
> Wouldn't it make sense to be an integer since its being added to an integer?
>
>>
>> Also, what about $obj1 + $obj2: Int? Float? Array?
>
> This is where operator over-loading would be useful however perhaps only
> explicit casts would make sense here.
>
>>
>> Another example: str_replace($obj1, "bar", "foo"); what to call?
>> __toString or __toArray? str_replace accepts both.
>
> This is an interesting situation, could be resolved by attempting a
> __cast('array') followed by a __cast('string') if the first call was
> rejected (false, exception or something).
>
>>
>> IMHO it would only make sense to invoke methods on explicit casts
>> only, otherwise it will just be a mess with PHP's current type
>> juggling. But, as we seen with __toString, limiting the field of
>> application was annoying (and it was later extended to nearly all
>> string usages).
>
> I would agree with this as well, only called during explicit casts.
>
>>
>> So, what will it be? Inconsistent and Confusing or Limited and Annoying?
>>
>
> One other alternative, probably not as easy would be to pass multiple types
> to cast, much the way the Accepts: HTTP header does, providing a list of
> possible cast types, in the preferred order.
>
> One could even implement an interface such as:
>
> interface Castable {
> function GetCastableTypes();
> }
>
> or some such.
>
>>> --
>>> 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
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
