If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

prototype property usage in js

A)is used for

1) Inheritance in js(JavaScript)? Is this the ONLY way of Inheritance in js?
derivedObj.prototype = new BaseObj();
or
2)adding properties/methods to an object, that added to Contractor of this obj?
in this case old objects that already instantiated will have as null this property?

let’s go for a "thank you".
1) no
2) no
B) no
more will require a "please".

The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.

syntax-wise both will work. the only difference between the two is that Object is a constructor for certain (so it will work as intended, although extending the JS base object is a no-go), while for myobject it depends, if it is a constructor--no problem, if it is an object instance (usually not a constructor) the prototype of the object (and not that of its constructor) is modified, i.e. only the prototype of this object. how useful that is depends on the situation.

note: that kind of statement is used when coding object extend functionality (inheritance).

The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.

out of principle. maybe except when you need to add core functionality where missing (like in IE).

reasons I would think of:
- improper for...in loops (I know that you won’t make that mistake)
- abuse (just because someone can do does not mean it is a good idea to)
- DOM will inherit it

The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.

out of principle. maybe except when you need to add core functionality where missing (like in IE).

reasons I would think of:
- improper for...in loops (I know that you won’t make that mistake)
- abuse (just because someone can do does not mean it is a good idea to)
- DOM will inherit it

so if it were done using Object.defineProperty() in a web worker thread, the only issue you'd have with it is "abuse"?

i'm not advocating this as a solution to the OP by any means, just probing the depths of javascript's acceptable practices.

there have been a few times where a temporary Object.prototype method has drastically slashed code repetition. granted one of those was a VBscript emulator project with heaps of other inescapable globals, but the others were used in production code to instantiate a facade.

Object.prototype, Object.defineProperty(), Function.prototype, eval(), and with(){} are the 5 most powerful pieces of javascript for those who don't want "java lite".

they provide right-now capabilities like classes and inheritance, composite types, continuations, generation, promises, and a lot more, and yet, we're told not to use most of them...

I've been wanting to use Object prototypes for years, i mean, it would be neat to have HTMLTableElement come with a .toCSV() or a .sortByColumn(n) method... or if form elements respected a magical data-persist attrib. or if <audio> had a .stop() method like every other media player API out there. With Object.defineProperty's non-enumerable capabilities, it could be our little secret.

since webworkers don't have a dom, do have their own global object, and suffer fewer inconsistencies in general, how about it; can i responsibly play with Object.prototytpe in workers?

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

I've been wanting to use Object prototypes for years, i mean, it would be neat to have HTMLTableElement come with a .toCSV() or a .sortByColumn(n) method... or if form elements respected a magical data-persist attrib. or if <audio> had a .stop() method like every other media player API out there. With Object.defineProperty's non-enumerable capabilities, it could be our little secret.

I’m not against modifying the prototype of those objects, just against that of the Object object.

Originally Posted by rnd me

since webworkers don't have a dom, do have their own global object, and suffer fewer inconsistencies in general, how about it; can i responsibly play with Object.prototytpe in workers?

I know WebWorkers too less to say for sure, but I am sure you would be responsibly playing with it. for others I am way less sure.

The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.

has been removed from strict JavaScript as being inefficient and unnecessary. Any code you could write using a with statement can be written without the with statement without any signigficant change to the number of characters the code will contain.

would simply give a syntax error because with is no longer a valid JavaScript command. You'd need to use the following instead in order for the code to actually run (which excluding all the spaces is just one character longer):

with is perfectly valid. your post seems to portray strict mode as some sort of desirable and common feature, which it shouldn't be. sure, if you turn the ES5 features off it doesn't work, but what kind of point is that? Simply un-disable the strict mode, or dispatch the call to a non-strict function.

I don't think any machines (yet) only implement strict. Even in useragents where ES5 strict is further along in development than the full (how could it not be), the full feature set still works.

ES5's Strict, formerly known as ES3CP, is simply a subset of the full spec. It's a less-capable implementation, one for which it's easier to write an interpreter. While they may be re-branding it as some sort of "noob-resistant" option, it's literally the exactly same thing as compact profile is ES3.

A conforming implementation of ES-CP SHALL support the global built-in object, but is NOT REQUIRED
to support the global eval() method (ES3 section 15.1.2.1).

A conforming implementation is NOT REQUIRED to support the with statement (ES3 section 12.10). If
with is not supported, use of a with statement results in a syntax error.

Is it a mere co-incidence that the two major diffs from ES5 to ES5s, and indeed the two you brought up, are the absence of with and eval, the exact same missing pieces in ES3CP? i think not.

according to the ES5 spec on page 4:4.2.2 The Strict Variant of ECMAScript

The ECMAScript Language recognises the possibility that some users of the language may wish to restrict
their usage of some features available in the language. They might do so in the interests of security, to avoid
what they consider to be error-prone features, to get enhanced error checking, or for other reasons of their
choosing. In support of this possibility, ECMAScript defines a strict variant of the language. The strict variant
of the language excludes some specific syntactic and semantic features of the regular ECMAScript language
and modifies the detailed semantics of some features.

i will say that the raw execution speed often goes down using with because there is more to be done inside a with than under normal circumstances. It can also make code faster, if it jumps over a few slot in the lexical name lookup chain. With is not always a performance hit and it can make perceived performance much higher.

one example of this is in game programming, where framerate is critical. The code you posted:

is problematic for using in a work loop because on each execution, it creates an object reference, d, that will need to be garbage collected.
garbage collection results in a user-noticeable pause as the stack needs to be frozen while it runs.
using with(), one can avoid the garbage-producing sides effects of namespace caching while having more readable code.

Last edited by rnd me; 11-14-2012 at 09:52 AM.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com