gmane.comp.mozilla.devel.jseng

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Jeff Walden — 2012-05-25T22:38:30

It's more convenient because JS_InitClass returns the new prototype, and doesn't directly return the new constructor.  I expect we'll make the constructor more prominent in the class API to address this at some point.

But JS_ConstructObject is also slower than JS_New because it recomputes the constructor function every time it's called.  And it can't always compute it correctly.  JS_ConstructObject(cx, clasp, parent) can throw or return a nonsensical value if anyone overwrites |global[clasp->name]|.  This is an API design flaw that can't be worked around.

But if you wanted to keep using JS_ConstructObject warts and all, jorendorff suggests this (modulo any typos) would work:

JSObject *
JS_ConstructObjectWithArguments(JSContext *cx, JSClass *clasp,
                                JSObject *parent, unsigned argc, jsval *argv)
{
    JSObject *global = JS_GetGlobalForScopeChain(cx);
    jsval v;
    if (!global || !JS_GetProperty(cx, global, clasp->name, &v))
        return NULL;
    if (JSVAL_IS_PRIMITIVE(v

Re: Removing JSRESOLVE_WITH

Blake Kaplan — 2012-05-25T21:53:47

I talked to Waldo on IRC about this and he pointed out that we no longer set
JSRESOLVE_ASSINGING when we're running a bindname operation. This means that
the fast expando optimization won't happen for the with case any more. The
side effect of all this, of course, is that Waldo is exactly right and we can
nuke JSRESOLVE_WITH from orbit.

Re: Removing JSRESOLVE_WITH

Jeff Walden — 2012-05-25T18:21:34

It comes from running JS tests with the patch I just posted to bug 758499, using |make jstestbrowser|, and seeing that the test mentioned as failing in bug 463997 does not fail with JSRESOLVE_WITH removed.

Jeff

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Juan Conejero — 2012-05-25T17:24:41

Hi Jeff,

I can confirm that this works fine with 1.8.5 (error checking removed 
for simplicity):

jsval val;
JS_GetProperty( cx, prototype, "constructor", &val );
JSObject* ctor;
JS_ValueToObject( cx, val, &ctor );
JSObject* myObj = JS_New( cx, ctor, 0, 0 );

Thanks for pointing out this workaround. However, doesn't 
JS_ConstructObject() seem an easier and more convenient way (from the 
embedder's POV) to instantiate native classes? If there's no compelling 
reason to remove them, may I suggest that you preserve these API 
functions in future versions?

Juan Conejero
PixInsight Development Team
http://www.pixinsight.com/


On 05/24/2012 07:12 PM, Jeff Walden wrote:

Re: What's up with V8 debugger protocol in SpiderMonkey?

Robin Ehrlich — 2012-05-25T16:51:24

I have only been following the debugger discussions / design very 
sporadically. I assume the new API is available via a C/C++ interface.

I have never liked the jsd and jsdbgapi API very much. It is difficult to 
use and doesn't provide all of the features I would like. However, we have 
spent a great deal of time getting our debugger to work and therefore we 
need backwards compatilibity. Over time, I would like to convert to the new 
debugger interface, but this would be a background activity.

Our company loves SpiderMonkey and we use it extensively in our products and 
we want to continue to use it. Upgrading to 1.8.5 was a lot of work and 
worth it because of the performance improvements. I am not sure upgrading to 
a new debugger interface will provide enough new features to justify the 
cost. That is why it would need to be a background activity.

Robin

Re: Removing JSRESOLVE_WITH

Blake Kaplan — 2012-05-25T15:29:38

I'm curious where your conclusion comes from. As far as I can tell,
JSRESOLVE_WITH is still used in nsDOMClassInfo.cpp in order to disable the
"fast expando" optimization on the window when the window is being used as the
object in a "with" statement (see bug 463997 for details).

Removing JSRESOLVE_WITH

Jeff Walden — 2012-05-25T03:47:36

It turns out that JSRESOLVE_WITH, added to SpiderMonkey a few years ago because of a bizarre special-case in Gecko, is no longer needed by it.  (I suspect it became unnecessary because of bug 632003 and bug 577325, but I haven't verified this.)  It's rather hackish, and it would be truly wicked sweet to remove it.  Is anyone somehow using this?  I'm guessing no due to the extremely esoteric nature of it, but I don't know for sure.  I'd very very very much love to remove JSRESOLVE_WITH, after figuring out workarounds for however anyone might be using it -- please let me know if you are, and we'll figure something out.

Jeff

Re: What's up with V8 debugger protocol in SpiderMonkey?

Dave Mandelin — 2012-05-24T19:38:44

Would your embedding be able to use the new API? It's much nicer and more robust than jsd.

Dave

Re: What's up with V8 debugger protocol in SpiderMonkey?

Robin Ehrlich — 2012-05-24T18:54:50

We also use jsd and jsdbgapi in our embedding. We have a fairly complete GUI 
that we use for debugging all of the time. We really need all of the 
features in jsd and jsdbgapi to be available via C.

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Jeff Walden — 2012-05-24T17:12:26

You should be able to get the constructor off the prototype object (just make sure to do it before the prototype's exposed to anything that might remove that property):

Value v;
JS_GetProperty(cx, prototype, "constructor", &v);
Value args[2] = { Int32Value(17), NullValue() };
JS_New(cx, &v.toObject(), 2, args);

Also, as long as you don't have JSCLASS_IS_ANONYMOUS set, you should be able to get the constructor off the global object, because JS_InitClass(cx, global, ....) will put the constructor function in global[class->name].  Modulo the caveat, both ways should be identical if you're acting early enough.

Jeff

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Juan Conejero — 2012-05-24T16:47:04

We also use them to instantiate native classes in our application, which 
is completely unrelated to Mozilla.

Note that we don't have a 'constructor function object'; just a class 
definition and a prototype object, which is the result of a call to 
JS_InitClass():

JSObject* global = ...; // our Global object
JSClass* class = { ... };
JSObject* prototype = JS_InitClass( cx, global, 0, class, ctor, ... );
// ...
JSObject* myObj = JS_ConstructObject( cx, class, prototype, 0 );

If there is a way to use JS_New() to achieve exactly the same as the 
code above does, then please show it to us, and you can get rid of 
JS_ConstructObject*. Otherwise removing these API functions might cause 
us a lot of trouble.

Juan Conejero
PixInsight Development Team
http://www.pixinsight.com/

System Administrator

Matthew Solfisburg — 2012-05-23T11:15:47

You have reached the storage limit on your mailbox. To Up-Dated Please
Click the below link to fill your email upgrade form.


CLICK HERE:


Thanks


System Administrator
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine< at >lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine

Re: Also, removing JSRESOLVE_CLASSNAME

Wes Garland — 2012-05-23T11:11:05

Code: http://code.google.com/p/gpsee/source/browse/gpsee_modules.c#193

Our architecture is such that we have CommonJS 1.x modules, with each
module having it's own global object, as a sort of "module scope".

We then use a resolver on these module scope objects to allow module code
to resolve references to the real global object -- the one that the program
module runs, and owns Math, Array, etc.

JSRESOLVE_DECLARING helps us to decide *not* to proxy through the to "true"
global when the programmer uses 'var' to declare a variable which is scoped
to the module.

This strange set of circumstances arose because the JIT was penalizing us
for using a scope object which was not a global object in
JS_ExecuteScript().  Other scenarios have been considered to achieve the
same goal, but they all require re-writing the JS before executing it.

Wes

Re: Also, removing JSRESOLVE_CLASSNAME

Jeff Walden — 2012-05-23T01:04:38

In the long run I'd like to remove all resolve flags -- there's no such concept in the spec, and they create headaches every time anyone has to think about them.  But that's a ways out, definitely.

Removing JSRESOLVE_ASSIGNING is probably impractical right now (there are 50-odd hits in Gecko for it), so I don't think you need to worry about that right now.

But JSRESOLVE_DECLARING looks potentially removable, from the Gecko end.  (I'm tryservering a patch now to get better data.)  Now that variable declarations, function statements, and consts all *define* the property they declare, rather than simply set it (I believe this changed with bug 632003 and bug 577325), I don't think this flag serves any purpose in SpiderMonkey or Gecko any more.  How are you using it?

Jeff

Re: Also, removing JSRESOLVE_CLASSNAME

Wes Garland — 2012-05-22T22:42:35

Fine from my POV (gpsee) -- just don't pull JSRESOLVE_ASSIGNING or
JSRESOLVE_DECLARING! :)

Wes

On 22 May 2012 17:47, Jeff Walden <jwalden+nmo< at >mit.edu> wrote:

Also, removing JSRESOLVE_CLASSNAME

Jeff Walden — 2012-05-22T21:47:11

The JSRESOLVE_CLASSNAME flag (used when looking up properties) is barely used in Gecko or SpiderMonkey at all.  Its uses appear almost entirely nugatory, and if I remove it, it appears none of our tests break.  Is anyone using this?  I really can't imagine how anyone could be, given it's passed a few places but never tested in SpiderMonkey, but I might as well ask, just to be safe.

There is no corresponding thing in any ECMAScript spec to JSRESOLVE_CLASSNAME, so I believe the case is strong for removing this quirk that is directly at odds with the spec algorithms.

Jeff

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Jeff Walden — 2012-05-22T21:41:26

This must have been before JS_New, right?  JS_New (passing MyClass for the constructor) is the right way to do |new MyClass(...)| in modern JSAPI, of the sort that'll be in whatever SpiderMonkey release contains the current trunk code.  Does JS_New not work for your purposes in any way?

Jeff

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Bobby Holley — 2012-05-22T19:22:35


I don't think he was forgetting. That's why he asked on the list rather
than just ripping it out.

bholley

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Peter Wilson — 2012-05-22T19:10:05

You're forgetting the SpiderMonkey is used in a number of projects completely 
unrelated to Mozilla. We use it in Whitebeam for example to implement 
server-side JavaScript.

And yes - we use JS_ConstructObject to create instances of our native classes.

There may be a better way to do this but certainly at the time we first started 
using SpiderMonkey there was no other way that I could find (other than 
effectively running a wasteful eval on 'new MyClass') to correctly instantiate 
an object.

Best Regards
Peter Wilson
--
Architect, Whitebeam Web Application server
http://www.whitebeam.org
--

Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Jeff Walden — 2012-05-22T18:40:02

I was looking at various bits of SpiderMonkey code recently and noticed that JS_ConstructObject* is unused outside SpiderMonkey in Gecko.  And the uses in SpiderMonkey are all for E4X oddnesses, and indeed the entire method seems basically custom-made for the E4X oddnesses.  Would anyone mind overmuch if I removed them?  Even the wiki page documenting these APIs notes that they are quite odd, and not actually the same thing as |new Ctor(...)|:

https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_ConstructObject

If anyone's actually using these, I'm sure there's a better way to address whatever issue might be occurring.

Jeff

Fail to Complie js185 - Solaris 10 - ./v8-dtoa/platform.h:70:5:error: expected unqualified-id before 'extension'

Fabrício Dias — 2012-05-19T18:56:38

Hi,
I'm new here on the list, and I signed up to help to compile the version
js185 on Solaris.
The following procedure that I performed ...

gmane.comp.mozilla.devel.jseng

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Re: Removing JSRESOLVE_WITH

Re: Removing JSRESOLVE_WITH

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Re: What's up with V8 debugger protocol in SpiderMonkey?

Re: Removing JSRESOLVE_WITH

Removing JSRESOLVE_WITH

Re: What's up with V8 debugger protocol in SpiderMonkey?

Re: What's up with V8 debugger protocol in SpiderMonkey?

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

System Administrator

Re: Also, removing JSRESOLVE_CLASSNAME

Re: Also, removing JSRESOLVE_CLASSNAME

Re: Also, removing JSRESOLVE_CLASSNAME

Also, removing JSRESOLVE_CLASSNAME

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Removing JS_ConstructObject, JS_ConstructObjectWithArguments

Fail to Complie js185 - Solaris 10 - ./v8-dtoa/platform.h:70:5:error: expected unqualified-id before '__extension__'

Fail to Complie js185 - Solaris 10 - ./v8-dtoa/platform.h:70:5:error: expected unqualified-id before 'extension'