44997 - JS "ECMA reference type" returns from host method support

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement, P3)

Description

[Brendan Eich [:brendan]]

I've got a patch that's not too big, and not too rickety a hack.  Comments 
please -- we would also need to consider extending Rhino to support such evil 
'o.item(i) = j' expressions.  The win here is obvious: help Mozilla consumers 
who want their customers "JScript" to run without change on non-Windows systems 
using Mozilla's JS engines.

/be

Comment 1

[Brendan Eich [:brendan]]

Attachment: patch to support ECMA reference types from natives

Comment 2

[Brendan Eich [:brendan]]

If we do this, it should be for js1.5 (and for rhino, I think, which also 
implements js1.5).

/be

Comment 3

[Brendan Eich [:brendan]]

Attachment: latest version of the patch

Comment 4

[Brendan Eich [:brendan]]

Attachment: js shell testcase

Comment 5

[Brendan Eich [:brendan]]

Norris, mccabe: any thoughts on extending Rhino to support this JScript-ism?

/be

Comment 6

[Brendan Eich [:brendan]]

People are crawling out of the woodwork wanting this "feature" (most recently in
private email to me; I urged my correspondent to post to mozilla-jseng with code
examples showing why he's in need of this patch).  If we can get a rhino patch,
I think we should do this for js1.5.


/be

Comment 7

[Norris Boyd]

So only a "native" function can return a reference type, as per ECMA, correct?

I guess the way we'd implement this in Rhino is to define a new interface with a 
callback for setting a value; functions that return references could be defined 
in Java as returning an instance of this new interface. Rhino would then ensure 
that the callback is invoked when the assignment occurs. 

Like you, I'm not too crazy about adding support for it, but I can see the 
motivation from the COM compatiblity side. 

Comment 8

[Brendan Eich [:brendan]]

Right, only "host functions" in ECMA parlance might contrive (through
unspecified means) to return a reference type.  It's important that such
functions, when called on the right-hand side of assignment, or otherwise in
"rvalue" contexts, evaluate per ECMA's [[GetValue]].  So Rhino would have to
call a getter when such a function returns the "Reference" interface type in an
rvalue context, and as you wrote, it would have to call the setter for lvalue
contexts.

Comment 9

[Brendan Eich [:brendan]]

Anyone working on a Rhino patch?

Janna guys, how is this patch treating you?

We need to get consensus for or against this patch going into Mozilla's JS 
engines, or even (gasp) into SpiderMonkey only.  I'll kick the newsgroup thread. 
I still think we should do this in Rhino and SM, or neither, but not only in SM.

/be

Comment 10

[Norris Boyd]

I haven't been working on a Rhino patch. Since the ability to return references 
from functions is only a property of native functions, it seems okay to me to 
only support it in SpiderMonkey. The only motivation seems to be COM 
compatibility, which is either irrelevant or less important to Rhino.

Comment 11

[Brendan Eich [:brendan]]

Norris: I hope you are right, but "JScript" may find its way into Rhino-based JS 
implementations too (server-side JScript, Rhino as the engine).  Time will tell. 
Is everyone else ok with adding this patch to SpiderMonkey?  Should we do so 
even if the XPIDL and XPConnect support for "parameterized attributes" is not 
there, and may not be agreed to by those subsystems' owners?

/be

Comment 12

[Mark G. Adams]

I think the patch is useful enough to be added, so at least that ECMA behaviour
can be done if so desired. IMO it is significantly less useful than it'd be if
it had XPIDL/XPCom mappings, since it still requires the programmer to
mix-and-match JS and XPCom, making the code uglier and less maintainable.

However, that's neither here nor there; at least the patch adds the basic
capabilities to the JS engine.

We actually haven't been using the patch, since this functionality's relatively
easily replacable by adding a new XPCom method to the class for replacing an
item at a given index. This does have the drawback of requiring changes in the
original scripting code, but this feature isn't too widely used and isn't worth
the price of being able to cleanly specify the class in XPCom as opposed to a
mixture.

My apologies for the delay in responding.

//Mark

Comment 13

[Brendan Eich [:brendan]]

Are we there yet?

What about XPIDL?

/be

Comment 14

[John Bandhauer]

I've done no xpidl/xpconnect work towards this. It sounds pretty low priority.

Comment 15

[Brendan Eich [:brendan]]

Fair enough.  janna guys, you feel the priority more -- can you cough up a 
patch?

/be

Comment 16

[Brendan Eich [:brendan]]

I fear this patch will rust or moulder if I don't check it in soon.  Does anyone
think I should not commit it?

/be

Comment 17

[Brendan Eich [:brendan]]

Attachment: up-to-date version of patch -- anyone out there care?

Comment 18

[Mike Shaver (:shaver emeritus)]

I want script support too, dammit, but I'll take a look.

Comment 19

[Brendan Eich [:brendan]]

Attachment: oops, forgot jsparse.c in last (up-to-date) patch

Comment 20

[Brendan Eich [:brendan]]

Attachment: argh, ignore that jsparse.c patch -- here's a complete patch

Comment 21

[Brendan Eich [:brendan]]

Attachment: final patch, a few decompiler gotchas to fix (visible only while tracing(1))

Comment 22

[Brendan Eich [:brendan]]

Shaver gave an r= already, but I went and changed things very slightly.  Other
than comment tweaks, I made sure that js_DecompileValueGenerator, which knows
all about assignment opcodes, knew about JSOP_SETCALL.  Note that JSOP_SETCALL
has format flag JOF_SET, but its mode is 0 (not JOF_NAME, JOF_PROP, or JOF_ELEM)
because o.item(i)=j is not i=j, o.i=j, or o[i]=j.  I could make a new mode, but
for now I'll use the "zero mode".

Everyone besides me who understands the decompiler, raise your hand.

/be

Comment 23

[Brendan Eich [:brendan]]

Checked in.  Hope someone uses it.

/be