Re: __toString(), __toArray()

From: Date: Wed, 13 Jan 2010 04:09:48 +0000
Subject: Re: __toString(), __toArray()
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-46672@lists.php.net to get a copy of this message
I don't move any magics,I am worried about your knowledge of php, there's people to give you money ? weird, set get call are only call when something doesn't exist catch or catch-able concept is to be able to catch any existing calls no the dynamic ones. On Tue, Jan 12, 2010 at 6:59 PM, Clint Priest <cpriest@warpmail.net> wrote: > > > Eddie Drapkin 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. > > I agree, moving all magic to a single function doesn't help the situation at > all, it simply complicates it. > > All this talk of "too many magic functions" is a little comical, its all > trying to overcome operator overloading type functionality in other > languages. > > __get()/__set() would be equivalent to getters/setters supported by the c# > language > > __toString(), __toArray() would be equivalent to operator String() in c++ ( > if I remember correctly ) > > I would definitely love to be able to, at the very least, cast an object to > an array but I figured a more general purpose __cast() would be most > beneficial to all. > > I think the ambiguity question for some functions accepting mixed as a > parameter type could be solved in aforementioned ways. > >> On Tue, Jan 12, 2010 at 9:11 PM, mm w <0xcafefeed@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 <oorza2k5@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 <0xcafefeed@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 >>>>> <chrisstocktonaz@gmail.com> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> On Mon, Jan 11, 2010 at 8:32 PM, mm w <0xcafefeed@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 > >

« previous php.internals (#46672) next »