prototype property usage in js

[lse123]

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?

B)prototype property used for anything else in HTML5 TECHNOLOGIES?

[Philip M]

Hello Ise12. Not heard of you for quite a long time.

You have 702 posts, and 0 thanks, and seem not to have encountered the words "please" and "thank you". So I will not be attempting to answer your latest questions. Perhaps someone else will do so.

It is your responsibility to die() if necessary….. - PHP Manual

[Dormilich]

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

[felgall]

I'll just add that in JavaScript as in most if not all languages objects don't have a Contractor - Contractors are people that you pay to write code for you.

[Labrar]

Maybe i am absolutely wrong but

PHP Code:

myobject.prototype=new CLASSNAME 


is wrong.

I'm not really sure if

PHP Code:

Object.prototype=new CLASSNAME 


will work.

So why won't you use a class directly.

PHP Code:

var call=new CLASSNAME 


and add your object in the next line?

A prototype does'nt make any sense in your case.

If you want to share attributes between objects, prototypes are useful.
But not in your case, if i understood right.

In the other Hand, you could use prototypes as a function. So you could call the methods from all your used Objects.

PHP Code:

<script type="text/javascript">
Object.prototype.addsomething=function(){
    this.added='Hello';
}
var h=new Object;
h.addsomething();
var x=new Object;
x.addsomething();
alert(h.added+' '+x.added);
</script> 


But what you're apparently looking for is a way to transmit from one object to another.
In that case you should do the old way.

PHP Code:

var call=new CLASSNAME 


Please correct me if i'am wrong or if there is a better way.

[Dormilich]

Originally Posted by Labrar

Maybe i am absolutely wrong but

PHP Code:

myobject.prototype=new CLASSNAME 


is wrong.

I'm not really sure if

PHP Code:

Object.prototype=new CLASSNAME 


will work.

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).

[rnd me]

Originally Posted by Dormilich

extending the JS base object is a no-go

still?

why?

[Dormilich]

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

[rnd me]

Originally Posted by Dormilich

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?

[Dormilich]

Originally Posted by rnd me

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.

[felgall]

Originally Posted by rnd me

with(){}

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.

For example:

<script type="text/javascript">
"use strict";
with (document.getElementById('something').style) {
   backgroundColor = '#ccc';
   color = '#f00';
}
</script>

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):

<script type="text/javascript">
"use strict";
var d = document.getElementById('something').style;
d.backgroundColor = '#ccc';
d.color = '#f00';
</script>

Also eval() works differently in strict JavaScript because it is no longer allowed to interact with variables outside of the eval itself.

[rnd me]

Originally Posted by felgall

with is no longer a valid JavaScript command.

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.

to wit, check out the ES3CP spec:

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:

var d = document.getElementById('something').style;
d.backgroundColor = '#ccc';
d.color = '#f00';

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.