When creating an object in JavaScript via a user-defined constructor, it's easy enough to "hook" (e.g. do something before or after) the creation of the object at runtime as the constructor is just a function. In fact, multiple Aspect Oriented Programming libraries exist to provide this functionality.
However, when using the object literal notation, the object seems to be automagically created by the runtime. Can the creation of these objects, or any other object in fact, be watched via the debugging protocol of V8?
My motivation here is to be able to trace data flow in an application.
Sorry, no, object literal instantiation cannot be watched.
Related
I am learning v8's source code and I found there are many definition about Object.
in include/v8-object.h
in src/objects/objects.h
in src/objects/js-objects.h
so what is the difference and how v8 handle the creation of Javascript Object (by literal or constructor)
Reading the sources would answer this question. The summary is:
include/v8-object.h defines v8::Object, which is the object class that's exposed on V8's public API. As the comment there says, it corresponds to a JavaScript object.
src/objects/objects.h defines v8::internal::Object, which is the superclass of anything on the managed heap (both JavaScript objects and various kinds of internal representations and internal metadata are subclasses of this).
src/objects/js-objects.h defines the internal representation of JavaScript objects.
how v8 handle the creation of Javascript Object
The short answer is: it allocates them on the managed heap.
The fully detailed answer is much longer than appropriate for a SO post, and changes all the time. Read the source code if you really care.
What do the recent standards say about extending host objects and their prototypes? E.g. is extending NodeList with a method _forEach or Document with a method _my_query properly defined?
Will I see anything I add to Object.prototype on host objects by the standard?
How do real implementations behave with respect to the relevant standards?
Note: I am not asking whether it is a good idea to extend host objects or their prototypes (although Object.defineProperty makes things a bit easier when it comes to enumerating issues).
ECMAScript 5 does not say anything about host objects' prototype chain.
This is defined in WebIDL.
Specifically, take a look at ECMAScript bindings section, which says:
Unless otherwise specified, the [[Prototype]] internal property of
objects defined in this section is the Object prototype object.
and this, from the following section:
Each ECMAScript global environment ([ECMA-262], section 10.2.3) must
have its own unique set of each of the initial objects, created before
control enters any ECMAScript execution context associated with the
environment, but after the global object for that environment is
created. The [[Prototype]]s of all initial objects in a given global
environment must come from that same global environment.
There's even an example:
iframe.appendChild instanceof Function; // Evaluates to true
Finally, Interface Prototype Object section says (emphasis mine):
The named properties object for a given interface A must have an
internal [[Prototype]] property whose value is as follows:
If A is not declared to inherit from another interface, then the value
of the internal [[Prototype]] property of A is the Array prototype
object ([ECMA-262], section 15.4.4) if the interface was declared with
[ArrayClass], or the Object prototype object otherwise
([ECMA-262], section 15.2.4).
Otherwise, A does inherit from another interface. The value of the
internal [[Prototype]] property of A is the interface prototype object
for the inherited interface.
So now if we look at DOM Level 3, and Document interface we can see that it inherits from Node interface. Node interface does not explicitly inherit from anything else, which means it inherits from Object.prototype.
This is theory :)
In practice, not all browsers follow this behavior, although most of the recent ones certainly do.
The ECMASCRIPT5 spec states :
A web server provides a different host environment for server-side
computation including objects representing requests, clients, and
files; and mechanisms to lock and share data. By using browser-side
and server-side scripting together, it is possible to distribute
computation between the client and server while providing a customised
user interface for a Web-based application.
Each Web browser and server that supports ECMAScript supplies its own host environment,
completing the ECMAScript execution environment.
I do not think it says anything else. This can be read to mean that an implementation can conform to the spec and implement the browser objects however it wants. This has been the case in the past. It does seem logical though to apply the power of the language to the external environment and I believe that all "modern" browsers now do that.
the dom/html elements have an prototype chain as follows:
HTMLElement > Element > Node > Object
hooking in anywhere in the chain where it makes the senes is probly the best bet.
I am excellent in Javascript, but currently started learning ActionScript. Can anyone teach me the difference between JavaScript Object and ActionScript Object ?
I request answer in few lines of description. Explanation with examples would be appreciated.
ActionScript has two different models in fact.
You can create classical ECMA-script objects either using literals or using the new-operator in conjunction with Function objects. Such objects work according to ECMA-standard.
You can create objects by instantiating ActionScript classes much like you would in Java for example. These objects ensure runtime type safety, i.e. if you try to assign a Foo value to a field typed as Bar you will get a runtime exception (or even a compile time exception if the object's type is known at compile time).
It should be noted, that you can compile AS3 with ECMA-script compatibility mode. In that case, AFAIK all objects will act as ECMA-script objects, sacrificing both execution speed and runtime type safety, but giving you flexibility.
Basically, Actionscript is a conventional Object Oriented Language in which it has Classes defining the structure of the objects instantiated.
JavaScript is a completely different flavour; you don't have access to Classes; you can emulate them (and that's a common trend for someone who's coming from a more conventional OOP mindset), but its strength comes exactly from the freedom you have. In a nutshell:
Objects are Functions - Functions are Objects
Objects are created in runtime, and can serve as a base (prototype), for creating other objects which, in its own advantage, can be morphed and override with new properties and methods, without having a strong bound to the strict definition of a class.
I just read this question: are there dictionaries in javascript like python?
One of the answers said that you can use JavaScript objects like Python dictionaries. Is that true? What is the performance of a key lookup in an object? Is it O(1)? Is adding a key to the object also constant time (hashing)?
The V8 design docs imply lookups will be at least this fast, if not faster:
Most JavaScript engines use a dictionary-like data structure as
storage for object properties - each property access requires a
dynamic lookup to resolve the property's location in memory. This
approach makes accessing properties in JavaScript typically much
slower than accessing instance variables in programming languages like
Java and Smalltalk. In these languages, instance variables are located
at fixed offsets determined by the compiler due to the fixed object
layout defined by the object's class. Access is simply a matter of a
memory load or store, often requiring only a single instruction.
To reduce the time required to access JavaScript properties, V8 does
not use dynamic lookup to access properties. Instead, V8 dynamically
creates hidden classes behind the scenes. [...] In V8, an object changes
its hidden class when a new property is added.
It sounds like adding a new key might be slightly slower, though, due to the hidden class creation.
Yes, you can assume that adding a key, and later using it for access are effectively constant time operations.
Under the hood the JS engine may apply some techniques to optimize subsequent lookups, but for the purposes of any algorithm, you can assume O(1).
Take a look at a similar question How does JavaScript VM implements Object property access? and the answer. Here I described the optimization technique used by JS engines and how it affects the key lookup performance. I hope these details help you write more efficient JS code.
I would like to know if the module pattern or Constructor/protoType pattern is more applicable to my work.
Basically I am using unobtrusive javascript -- the HTML document has a reference to the .js file.
My understanding of the module pattern:
call an INIT method (which is basically a public method i can create and return using the module pattern)
In the INIT method, assign all click events etc.
This sounds like the perfect pattern for my situation, as I don't need to create Objects and inheritance hierarchies etc.
My understanding of the Constructor/Prototype pattern:
for creating objects
for using inheritance (i.e. Subtypes of a supertype)
Am I correct, that for providing unobtrusive javascript, the module pattern is ideal?
Constructor-functions and prototypes are one of the reasonable ways to implement classes and instances. They don't quite correspond to that model so you typically need to choose a particular scheme or helper method to implement classes in terms of prototypes. (Some background on classes in JS.)
The module pattern is typically used for namespacing, where you'll have a single instance acting as a store to group related functions and objects. This is a different use case from what prototyping is good for. They're not really competing with each other; you can quite happily use both together (eg put a constructor-function inside a module and say new MyNamespace.MyModule.MyClass(arguments)).
Module pattern is by far easier and more elegant than prototype. However, thinking mobile first. It is not a relevant pattern for medium/large objects because the initialization needs to parse the whole block before starting. The multiple closures also create circular dependencies that the garbage collector does not free (especially IE), it results in a heavier memory footprint not freed until the window (or tab) is closed - check chrome task manager to compare-
The loading time is inversely proportional to the object size using module pattern while this is not the case for prototypal inheritance.
Statements above are verified through multiple benchmarks like this one: http://jsperf.com/prototypal-performance/54
As seen in last test. Small objects are better off being initialized as plain object ( without these patterns). It is suitable for single objects not requiring closure nor inheritance. It is wise to assess if you even need these patterns.
Prototype pattern helps us to extend the functionality and there is only one instance of functions in a memory irrespective of the number of objects. In Module patter, each object creates a new instance of functions in memory but it provides with concept of private/public variables and helps in encapsulating the variables and functions.