On 2011-03-11, at 15:43, Donald Anderson wrote:
> Tucker,
>
> About this comment:
>
> 4. CommonGenerator: "prototype" is _not_ a property of Object instances, only
> of Function instances (and hence of our Classes, which are implemented as
> ECMAScript Functions. Function instances also have length, apply, and call
> as properties.
>
> I think the right thing is to separate the symbols: 'prototype', 'length',
> 'apply', 'call', and pull them out of possibleInstance, but only when we are
> in a method in on of our classes. How do I tell if we're in one of our
> classes? I don't see a pragma I can hang my hat on. Is there some trick I'm
> missing, or should I create a pragma in ClassModel that indicates this?
Let me reprhase:
Our _instances_ are JS Object's. Object does not inherently have any of those
properties. Hence references to them in instance are not instance references.
Bottom line: I'm just saying leave those out of the table.
---
There's a separate issue: that people might like lexical references to class
statics in instance methods to resolve automatically. Right now we don't do
that at all in the JS back-end. It happens for free in swf10. But I think
that is a separate improvement, along the same lines, but not part of the
with(this) task.
[Our _classes_ are JS Function's, which _do_ have those properties, so we might
choose to treat them as implicit class static properties, if/when we
automatically resolve references to class statics, but I don't think many
languages do that.]
---
Here's some Rhino output that may be illustrative:
js> clas = function () {}
function () {
}
js> clas.prototype
[object Object]
js> clas.length
0
js> clas.apply
function apply() { [native code for Function.apply, arity=2] }
js> clas.call
function call() { [native code for Function.call, arity=1] }
js> inst = new clas()
[object Object]
js> inst.prototype
js> inst.length
js> inst.call
js> inst.apply
js> inst.constructor
function () {
}
js> inst.constructor.prototype == clas.prototype
true
js>
> - Don
>
> On Mar 11, 2011, at 3:03 PM, P T Withington wrote:
>
>> Another test case we need to verify:
>>
>> <class name="stateTest">
>> <attribute name="attr" value="42" />
>> <state applied="true">
>> <method name="stateMethod">
>> return attr;
>> </method>
>> </state>
>> </class>
>>
>> <state>s are funny in that they 'donate' their methods to the parent node.
>> We may have some work to do there. Perhaps we will have to turn off the
>> optimization for now and file an improvement to fix the way state methods
>> work.
>
>
> --
>
> Don Anderson
> Java/C/C++, Berkeley DB, systems consultant
>
> voice: 617-306-2057
> email: [email protected]
> www: http://www.ddanderson.com
> blog: http://libdb.wordpress.com
>
>
>
>
>
