I am not forcing anything, it's already there, that's definitely a
more useful magic, if people would add a new one, __cast is not
critical, catchable objects are __catch even if exists, so my point I
'd rather see useful requests than a unseful one e.g __cast

from my perspective __toString and __toArray , __callStatic should be
removed  __callStatic  is definitly a mistake.



On Tue, Jan 12, 2010 at 6:29 PM, Eddie Drapkin <oorza...@gmail.com> wrote:
> What you're proposing is just forcing __call, _callStatic, __get and
> __set into a single method, which does nothing to reduce the amount of
> magic, only obfuscate it.  And it certainly offers no alternative to
> "__cast", at least not that I can see.
>
> On Tue, Jan 12, 2010 at 9:11 PM, mm w <0xcafef...@gmail.com> wrote:
>> the multiplication of magic, the pointed point, need to read more carefully
>>
>> On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin <oorza...@gmail.com> wrote:
>>> How does this have *anything* to do with the discussion at hand?
>>>
>>> On Tue, Jan 12, 2010 at 9:09 PM, mm w <0xcafef...@gmail.com> wrote:
>>>> don't worry it's only for people who are working with MVC and
>>>> RootObject structure, there is too much magics already and __cast is
>>>> not needed at all,
>>>> as we cannot monkey patch to add an observer on itself, a nice
>>>> solution should have a catchable object so __catch any calls
>>>>
>>>> function __catch($data, $type) {
>>>>    if (method == $type) {
>>>>         if (data[selector] = 'setValue' && observedValueForKeyPath) {
>>>>             $this->_setValue(($data['arg']);
>>>>             return;
>>>>         }
>>>>    }
>>>>    continue_natural_call();
>>>> }
>>>>
>>>> we could imagine to have a root-object-built-in-class that is
>>>> naturally observable, or a root classObject at all, anyway it's only
>>>> something for people who are doing OO programming,
>>>> so don't worry
>>>>
>>>> On Tue, Jan 12, 2010 at 2: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;
>>>>>
>>>>> 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
>>>>
>>>>
>>>
>>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to