Re: __toString(), __toArray()
| From: | Ionut G. Stan | Date: | Wed, 13 Jan 2010 10:22:35 +0000 |
| Subject: | Re: __toString(), __toArray() | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-46677@lists.php.net to get a copy of this message | ||
It appears that, mm w is talking about some aspect oriented feature.
I would welcome a magic method that would intercept calls/access to existing methods/properties (not only inaccessible ones), in the same sense that __getattribute__ works in Python for example IIRC. It may also be a good time to unify properties and types in PHP (we see a lot of problems with lambdas assigned to object properties).
But... that's certainly another topic.
On 1/13/2010 6:09 AM, mm w wrote:
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:-- Ionut G. Stan I'm under construction | http://blog.igstan.ro/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:-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phpthe 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:-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phpcast is not needed in PHP i 'd rather be more interesting in class Obj {What? ...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(); } }}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); // 1Etienne Kneuss wrote: This is where operator over-loading would be useful however perhaps only explicit casts would make sense here.