| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Added an extra argument to JSObject::getPropertyNames() that
specifies if the non-enumerable properties (those with the
DontEnum attribute set) should be included or not.
Tried looking at using a unsigned as an attribute-inclusion
or exclusion filter, but the semantics of either the calling
or the callee code would be very strange so I opted out.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so native function that would call
engine->evaluate("var b = 'foo');
would not change the global object.
The change in qscriptengine.cpp makes sure that the correct scope is
used for the execution of QScriptEngine::evaluate.
The changes in qscriptfunction.cpp push a new scope for native function
calls. We might want to move that into QScriptContext later
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JSC requires that the global object is actually a
JSGlobalObject instance, whereas QScriptEngine::setGlobalObject()
allows any object to be set as the global object. The way we
solve this is by proxying from an internal global object to the
custom (user-set) object.
We need to take care that the internal global object is never
actually exposed through our API; a brilliantly named helper
function, toUsableValue(), makes that happen.
Evaluating "var a = 10" with a custom global object doesn't work
yet; the variable always ends up in the internal Global Object.
For variable assignments, JSC appears to bypass the normal
JSObject::put() and instead use
JSGlobalObject::copyGlobals{From,To}(), which means I can't
intercept and proxy the assignments.
This commit enough to get the Context2D example working. There's
another bug with iteration of the built-in Global Object's
properties (non-enumerable properties are always skipped by the
JSC C++ API, whereas with QScriptValueIterator they should not
be), but that's a totally separate issue.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Install custom ClientData on JSGlobalData instance instead.
Also some cleanups to avoid globalObject et al being accessed
directly.
Killed the proxying scheme employed in setGlobalObject() since it
didn't work; if you stored the original Global Object and replaced
it with another object, then added properties to the new object,
they would show up in the old object, too (because the old object
would always proxy to whatever the current Global Object was).
|
|
|
|
|
|
|
|
|
| |
Use the exception from JSC::exec instead of
QScriptEngin::uncaughtException.
A few more tests are passing for qscriptvalue and qscriptqobject.
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
|
| |
Fix tst_QScriptExtQObject::objectDeleted(), the exception generated
in the JSC script engine needs to be stored in uncaughtException of
QScriptEngine.
Reviewed-by: Kent Hansen
|
|
|
|
|
| |
No need to expose the fact that we go via the Global Object
to get an engine pointer.
|
|
|
|
|
|
|
|
| |
For matching the regular expression, the algorithm of JSCore is used
instead of QRegExp, this is done to be consistent with the rest
of ecmascript.
Reviewed-by: Kent Hansen
|
|
|
|
| |
getter
|
| |
|
|
|
|
|
| |
Don't add method names, only signatures.
Respect the SkipMethodsInEnumeration option.
|
| |
|
|
|
|
|
| |
Doesn't actually replace the global object, but rather has the
standard global object act as a proxy to the custom one.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The argument conversion logic checks for exceptions after
attempting to convert each argument; this requires that there
is initially no exception, otherwise it's going to bail out
even if the conversion itself succeeded.
|
|
|
|
|
| |
Caller is responsible for calling marked() before mark(),
otherwise you might get infinite recursion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With an object created by QScriptEngine::newObject(), it should
be possible to call QScriptValue::setClass() to dynamically
change the behavior of that object. Similarly, it should be
possible to promote plain script objects to QObject (QVariant)
wrappers by calling the overload of QScriptEngine::newQObject()
(newVariant()) that takes a script object as the first argument.
This commit implements this capability.
The premise is the (internal) QScriptObject class, which inherits
JSC::JSObject. It reimplements all the methods for getting/setting
properties etc. Then there's a level of indirection to facilitate
dynamic change of the class: Each QScriptObject can have a
delegate associated with it that will handle operations on the
object. By default there is no delegate, so the object behaves as
a normal JS object, as you expect. However, once a delegate is set
(e.g., when QScriptValue::setScriptClass() is called),
QScriptObject will give the delegate the chance to handle the
object operation.
In addition to a delegate implementation for QScriptClass-based
objects, there are also delegates for QObject and QVariant
wrappers. These replace the QObjectWrapperObject and
QVariantWrapperObject classes.
|
|
|
|
| |
Follow behavior of old back-end. Makes qscriptable test pass.
|
|
|
|
|
| |
Makes sure that new stack frame is set up if the function is
native, and all that.
|
| |
|
|
|
|
|
| |
Setters don't work yet. But hey, the defaultprototypes
example finally works.
|
|
|
|
|
| |
With commit 6985212c8909c89183b232ca28b96a2c8a2f1385,
context->thisObject() now returns the right thing.
|
| |
|
|
|
|
| |
Do it The right way(TM), by lazily wrapping JSC::ExecState objects.
|
|
|
|
| |
Implement delete operator for Qt properties.
|
| |
|
|
|
|
| |
Not fully working yet, so disabled for now
|
| |
|
| |
|
| |
|
|
|
|
| |
Makes the args, thisObject etc. available if QScriptable is used.
|
| |
|
| |
|
|
|
|
| |
Makes variant conversion work for signal handlers.
|
| |
|
| |
|
|
|
|
| |
Makes more tests pass.
|
| |
|
|
|
|
|
| |
The JSC function was renamed, so we need to do so too, otherwise
we call the function defined in the base class.
|
|
|
|
|
| |
Not everything passes but at least nothing asserts anymore, so
the test runs to completion.
|