Newsgroups: php.internals,php.internals Path: news.php.net Xref: news.php.net php.internals:46669 php.internals:46670 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53115 invoked from network); 13 Jan 2010 02:59:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2010 02:59:45 -0000 X-Host-Fingerprint: 75.72.251.154 c-75-72-251-154.hsd1.mn.comcast.net Received: from [75.72.251.154] ([75.72.251.154:6161] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 32/FF-06421-0273D4B4 for ; Tue, 12 Jan 2010 21:59:44 -0500 To: internals@lists.php.net Message-ID: <4B4D371D.3010200@warpmail.net> Date: Tue, 12 Jan 2010 20:59:41 -0600 User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: internals@lists.php.net References: <3A.94.26332.3E9EB4B4@pb1.pair.com> <68de37341001121810x10be424fu842402a398d3709e@mail.gmail.com> <68de37341001121829p3a2f6a62y6eb2a45863e62ae6@mail.gmail.com> In-Reply-To: <68de37341001121829p3a2f6a62y6eb2a45863e62ae6@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 75.72.251.154 Subject: Re: [PHP-DEV] __toString(), __toArray() From: cpriest@warpmail.net (Clint Priest) 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 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 >>>> 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 >>>> >>>>