First of all, thank you Johannes for posting the bug. I entered some code in the comments.
Second, yes it's a bug. Retrieving the property isn't the issue. Executing it as a function is. For example: mp['prop'] = 'something'; Why doesn't that execute getProperty? If it did Proxy would be completely useless. How would you know what was trying to be set or that a set action was being attempted at all? The same applies to a function call. The fact is a method is being called - the player expects it, that's why you get a runtime error if you don't return a function. Functionally, there's no difference here: mp['go'](); mp.go(); We are accessing the same property. go is a property that references a function, in BOTH cases. Why would getProperty not be called for both? Why is there a callProperty method at all? There's a difference between: var a = mp['go']; and: var a = mp['go'](); Just as there's a difference between: var a = mp.go; and: var a = mp.go(); mp['go'] requires a lookup, the same as mp.go requires a lookup. The latter calls the function directly but the other does not? A peer of mine suggested this may be a compiler bug rather than a player bug. It's possible that the compiler is treating the [] as a property lookup that needs to call getProperty, ignoring the fact that a function is being called. At least that's our suggestion from the outside. The compiler/player team would know best. Fwiw, check this entry in the Flash Player 10 bug list. This is a bug listed that suggests a similar behaviour: https://bugs.adobe.com/jira/browse/ASC-2298 ------------------- myXML:XML = new XML('<a>test</a>'); trace(myXML['toXMLString']()); Actual Results: TypeError: Error #1006: value is not a function. Expected Results: <a>test</a> ------------------- That happens because, I'll bet, under the covers the E4X implementation is doing the same thing as Proxy. When you type myXML.somenode you get back a reference to the node, but it doesn't exist on myXML directly. The reason all of the members of XML are methods is so they don't conflict with this process. The reason the above code fails is because getProperty is being called and XML is doing a lookup on the data, not finding it, or finding it, whatever the case, but not returning the method as expected. A workaround in that case is to lookup the XML methods first and return them if found, but then you have conflicts, a problem that using methods was supposed to resolve. The solution is to have callProperty called. On 9/27/07, Johannes Nel <[EMAIL PROTECTED]> wrote: > > and here is the bug id: > http://bugs.adobe.com/jira/browse/ASC-2812 > > > On 9/27/07, Johannes Nel < [EMAIL PROTECTED]> wrote: > > > > as a side note, someone on the player team did think this was a bug > > before i logged it post i escalated it to people who know more people than i > > do :) > > > > On 9/27/07, Johannes Nel <[EMAIL PROTECTED]> wrote: > > > > > > var mo:MyOther = new MyOther(); > > > var mp:MyProxy = new MyProxy(); > > > mo.nextfunction = mp['go'] > > > > > > this is a very good point. > > > > > > > > > > > > On 9/27/07, actionscript_czar <[EMAIL PROTECTED] > wrote: > > > > > > > > This doesn't seem to be a bug to me, just looking at it from a > > > > limited perspective. > > > > > > > > Image a class that lookes like this: > > > > > > > > class MyClass > > > > { > > > > public var go:Function; > > > > > > > > public function MyClass( goFunc:Function ) > > > > { > > > > this.go = goFunc; > > > > } > > > > } > > > > > > > > In this case go is a property that happens to be a function object. > > > > So what if using your proxy with another class you did something > > > > like > > > > this: > > > > > > > > var mo:MyOther = new MyOther(); > > > > var mp:MyProxy = new MyProxy(); > > > > mo.nextfunction = mp['go']; // could also be mp.go > > > > > > > > In that case it would use getProperty and your description is no > > > > different. When you use the [] operators it gets the property then > > > > you use the () operators to call the property. The () property is > > > > expecting a function object on the left hand side. The reason it > > > > doesn't use callProperty is because the () operators only see a > > > > function object but don't see it as part of the MyProxy object. > > > > > > > > This doesn't mean it couldn't work as you expect in the future, but > > > > my understanding says the two methods of getting to go are processed > > > > > > > > distinctly for a reason. > > > > > > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, > > > > "Derek Vadneau" <[EMAIL PROTECTED]> > > > > > > > > wrote: > > > > > > > > > > There seems to be a bug in flash.utils.Proxy. Here's some sample > > > > code: > > > > > > > > > > var mp:MyProxy = new MyProxy(); > > > > > > > > > > mp.myVar = 'something'; // calls flash_proxy setProperty as > > > > expected > > > > > > > > > > mp['myVar'] = 'something'; // calls flash_proxy setProperty as > > > > expected > > > > > > > > > > mp.go(); // calls flash_proxy callProperty as expected > > > > > > > > > > mp['go'](); // calls flash_proxy getProperty - NOT expected > > > > > > > > > > Why is getProperty called where the [] operator is used instead of > > > > > > > > the > > > > > . operator in the case where a function is being called, but not > > > > when > > > > > setting a property? > > > > > > > > > > And in that case you MUST return a function or a runtime error > > > > will > > > > be thrown. > > > > > > > > > > This is unexpected behaviour, as far as I can see. > > > > > > > > > > Another example: > > > > > > > > > > mp.obj.go(); > > > > > > > > > > mp['obj']['go'](); // getProperty is called twice, callProperty is > > > > > > > > NOT > > > > > called at all > > > > > > > > > > The issue is that I am dealing with a dynamic API, so I don't > > > > always > > > > > know that 'obj' or 'go' is a property vs. a method. > > > > > > > > > > But, because the getProperty is called when a callProperty should > > > > be > > > > > called I am passing an instance of my Proxy class and a runtime > > > > error > > > > > is thrown. > > > > > > > > > > -- > > > > > > > > > > Derek Vadneau > > > > > > > > > > > > > > > > > > > > > > -- > > > j:pn > > > \\no comment > > > > > > > > > > -- > > j:pn > > \\no comment > > > > > -- > j:pn > \\no comment > > > -- Derek Vadneau
