Privileged constructor members

[John G Harris]

Any sufficiently large code base needs a contract system, especially
in a team development environment where not all members are
equivalently skilled.


A relatively small gain in execution speed is not worth the loss of a
"guarantee" on the value types being passed as parameters.

On would think that removing type checks would have the opposite
effect.

But does not reduce maintenance cost when debugging

Not all developers can code and forget, some of us actually maintain a
code base for years and have to see beyond the immediate goal to the
net costs of a project. This is off-topic though, and not worth
pursuing.

Obviously, if your coders aren't able to use interfaces in the way
required by the documentation then you have to put in vast amounts of
vetting and special case code. That, in turn, means you have to write
test cases for *all* the ways of doing things wrongly. My view, and I'm
not alone, is that that's going to be quite a burden.

John

 

[Thomas 'PointedEars' Lahn]

"less verbose" is defined in this context the same way as it is in
common usage: "fewer words"

At least for me, verbosity encompasses greater thoroughness in description,
not merely more words.

What I just achieved in my last message

A correct answer no doubt, but one that does not lead anywhere.

I believe this is an irrelevant question

Obviously in general it is not; it may be in your case.

Yes, I am aware of implementation support, and this is not an issue in
the environment I am using this for.

You should have said that before.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Here is a simplified re-posting of the pattern I've come up with that
avoids this problem:

-------------------------------------------------------------------

function XmlDeclaration(version, encoding, standalone) {
var _encoding,
_len = arguments.length,
_standalone,
_version;

//...

Object.extend(this,{

That method does not appear to be defined in JavaScript 1.8.1 as of Gecko
1.9.1/Firefox 3.5.1. What exactly does it do?

get encoding(){
//...
},
set encoding(v){
//...
},
get standalone(){
//...
},
set standalone(v){
//...
},
get version(){
//...
},
set version(v){
//...
}
})

this.toString = function(){
//...
}

If Object.extend() merely augmented the object referred to by the first
argument with a number of properties, why are you using this separate statement?

If it added properties to the prototype object of the constructor of the
referred object instead, why would you not write

Object.extend(XMLDeclaration.prototype,
{
...
});

outside of the constructor instead, which would be much more efficient?

And you should end all your statements with a semicolon.

}

You should be aware that you cannot rely on having JavaScript 1.8.1 support
exactly; the actual version may be greater and may implement this
proprietary feature differently.


PointedEars

 

[Jorge]

Not using `arguments' where it should be used, or going to great lengths to
avoid using `arguments' when not necessary, makes code more error-prone and
harder to maintain.  A good example of that is the shortsighted
recommendation to name one's function expressions in order to avoid using
`arguments.callee' ("because it is inefficient", "because ES 3.1/5 Strict
Mode does not allow it" etc.); that identifier will leak into the outer
scope in all known implementations of JScript that support named function
expressions (google "function statement").

When a notorious JScript bug such as that is long standing over a
decade, it should be embarrassing for M$, but it isn't.

Instead, most (long standing) web developers have developed a culture
in which The-Right-Thing-To-Do is whatever runs fine in JScript. But
it should *not* be so.

Where JScript has a bug, M$ ought to fix it and web developers ought
to stop once and for all swallowing -quietly and blindly- any of M$'s
many (against-the-web) poisoned pills.

 

[Doug Miller]

At least for me, verbosity encompasses greater thoroughness in description,
not merely more words.

Quite the opposite is true. I encourage you to find a good dictionary of the
English language and educate yourself as to the *actual* meaning of the word.

 

[Tim Down]

When a notorious JScript bug such as that is long standing over a
decade, it should be embarrassing for M$, but it isn't.

Instead, most (long standing) web developers have developed a culture
in which The-Right-Thing-To-Do is whatever runs fine in JScript. But
it should *not* be so.

Where JScript has a bug, M$ ought to fix it and web developers ought
to stop once and for all swallowing -quietly and blindly- any of M$'s
many (against-the-web) poisoned pills.

This is a tired old argument. Yes, we'd all like Microsoft to fix bugs
in JScript. Good browser scripting isn't really about the ideal,
though, is it? A browser scripter who writes code that works in a wide
range of browsers, including Microsoft's, is better than one who
refuses to write code that works in IE.

Tim

 

[-TNO-]

That method does not appear to be defined in JavaScript 1.8.1 as of Gecko
1.9.1/Firefox 3.5.1.  What exactly does it do?

This method is defined in Mozilla Bug 433351 for future implementation
(https://bugzilla.mozilla.org/buglist.cgi?quicksearch=object.extend)
It is also defined in the es-discuss mailing list for likely future
inclusion in the standard "ES3.1 Object static methods rationale
document" at (https://mail.mozilla.org/pipermail/es-discuss/2008-July/
thread.html#6664)

The definition:

--------------------------------------------------

Object.extend = function(orig) {
if ( orig == null )
return orig;

for ( var i = 1; i < arguments.length; i++ ) {
var obj = arguments;
if ( obj != null ) {
for ( var prop in obj ) {
if ( obj.hasOwnProperty( prop ) ) {
var getter = obj.__lookupGetter__( prop ),
setter = obj.__lookupSetter__( prop );

if ( getter || setter ) {
if ( getter )
orig.__defineGetter__( prop, getter );
if ( setter )
orig.__defineSetter__( prop, setter );
} else {
orig[ prop ] = obj[ prop ];
}
}
}
}
}

return orig;
};

------------------------------

If Object.extend() merely augmented the object referred to by the first
argument with a number of properties, why are you using this separate statement?

If it added properties to the prototype object of the constructor of the
referred object instead, why would you not write

  Object.extend(XMLDeclaration.prototype,
    {
      ...
    });

outside of the constructor instead, which would be much more efficient?

Defining getter/setter pairs outside of the constructor removes its
privileged access to private variables as can be seen here:

-----------------------------------
function Complex(a,b,c) {
var _a = a,
_b = b,
_c = c;

Object.extend(this,{
get a(){
return _a
},
set a(v){
_a = v
},
get b(){
return _b
},
set b(v){
_b = v
},
get c(){
return c
},
set c(v){
_c = v
}
})
this.toString = function(){
return _a + "," + _b + "," + _c
}
}

function Complex2(a,b,c) {
var _a = a,
_b = b,
_c = c;

this.toString = function(){
return _a + "," + _b + "," + _c
}
}
Object.extend(Complex2.prototype,{
get a(){
return _a
},
set a(v){
_a = v
},
get b(){
return _b
},
set b(v){
_b = v
},
get c(){
return c
},
set c(v){
_c = v
}
})


var foo = new Complex(1,2,3)
foo.b = "B"
print(foo.toString())

var foo2 = new Complex2(1,2,3)
foo2.a = "A"
print(foo2.toString())
----------------------------------

And you should end all your statements with a semicolon.

I should also be consistent with my spacing, but that's nitpicking at
this point I think. Besides, "all" statements would be an incorrect
assertion since its unnecessary in some cases (function declarations
for example).

You should be aware that you cannot rely on having JavaScript 1.8.1 support
exactly; the actual version may be greater and may implement this
proprietary feature differently.

This versioning is explicitly set in my usage, and maintenance of the
code will be done relatively often.

 

[Jorge]

This is a tired old argument. Yes, we'd all like Microsoft to fix bugs
in JScript.

And up until now you could do nothing but to bear with it because IEs
were the one and only browser with nearly ~ 100% of the marketshare.
This is no longer so and it's time to stop suffering development for
the most broken browser. In order to let ordinary people, web users
(not developers) know what's going on, web sites ought to start
complaining about broken browsers, instead of -as has been being done
until now- covering it up.

Good browser scripting isn't really about the ideal,
though, is it? A browser scripter who writes code that works in a wide
range of browsers, including Microsoft's, is better than one who
refuses to write code that works in IE.

I don't agree. I'm not willing to waste any time learning the hundreds
of bugs that M$ has gifted us nor its possible workarounds, and it's a
pity that others have had to do so for so long. So many many man-hours
wasted for no good. Pitiful. Web developers ought to (be willing to)
attempt to educate the users about badly broken browsers, now that
there are four excellent alternative browsers to choose among.

 

[Richard Cornford]

On Aug 27, 5:24 am, Thomas 'PointedEars' Lahn wrote:

I should also be consistent with my spacing, but that's nitpicking
at this point I think. Besides, "all" statements would be an incorrect
assertion since its unnecessary in some cases (function declarations
for example).

<snip>

Function declarations are not statements. In ECMAScript terms
FunctionDeclaration and Statement are the two (distinct and mutually
exclusive) types of SourceElement.

If you want an example of a statement that is not (ever) semi-colon
terminated then the Block statement would be a better example (as
might switch).

Richard.

 

[Thomas 'PointedEars' Lahn]

That method does not appear to be defined in JavaScript 1.8.1 as of
Gecko 1.9.1/Firefox 3.5.1. What exactly does it do?

This method is defined in Mozilla Bug 433351 for future implementation
(https://bugzilla.mozilla.org/buglist.cgi?quicksearch=object.extend)
It is also defined in the es-discuss mailing list for likely future
inclusion in the standard "ES3.1 Object static methods rationale
document" at (https://mail.mozilla.org/pipermail/es-discuss/2008-July/
thread.html#6664)

The definition:
[...]

Thanks. But is there a runtime environment actually provides it natively,
and if yes, which?

Defining getter/setter pairs outside of the constructor removes its
privileged access to private variables

Ah yes, of course.

as can be seen here:

Thanks. You might want to review my Map implementation.

I should also be consistent with my spacing, but that's nitpicking at
this point I think.

Just an observation and a recommendation. Make use of it as needed.

Besides, "all" statements would be an incorrect assertion

If I had been more exact (like, "but not necessarily if the Statement is a
Block, IfStatement, IterationStatement, WithStatement, SwitchStatement or
TryStatement") you might have accused me of nitpicking again.

since its unnecessary in some cases (function declarations
for example).

As the name says, function *declarations* are _not_ statements. The
relevant production can be found in ES3F, section 14:

| SourceElement :
| Statement
| FunctionDeclaration

This versioning is explicitly set in my usage, and maintenance of the
code will be done relatively often.

And thus be quite expensive, I imagine. Anyhow, that's your business.


PointedEars

 

[-TNO-]

Thanks.  But is there a runtime environment actually provides it natively,
and if yes, which?

Not one that is publicly available at this time that I am aware of.

Thanks.  You might want to review my Map implementation.

Do you have a direct link? I'm always interested in possible
alternatives.

Just an observation and a recommendation.  Make use of it as needed.

No offense meant of course.

 

[Jorge]

Those being FF, Opera, Safari, and Chrome?

Yes... why do you ask ?

 

[Thomas 'PointedEars' Lahn]

Not one that is publicly available at this time that I am aware of.

ACK. So that which you are using is not native, or have you managed to
modify the script engine accordingly?

Do you have a direct link? I'm always interested in possible
alternatives.

There has been a discussion about it here (in general, about ways to work
around the restrictions on property names imposed by the prototype chain
mechanism) here recently. You can find the version to be subject of that
discussion at <http://PointedEars.de/scripts/test/map.js>. Especially
kangax has provided useful advice in the thread that has been incorporated
in the local version.

No offense meant of course.

ACK


PointedEars

 

[-TNO-]

ACK.  So that which you are using is not native, or have you managed to
modify the script engine accordingly?

I've actually written a self hosted, browser based JS1.8.1+ "compiler"
that targets JavaScript 1.5 natively in the browser on the fly. There
are a number of language productions that aren't supported properly
yet, so I'm unwilling to release it publicly at this time.

There has been a discussion about it here (in general, about ways to work
around the restrictions on property names imposed by the prototype chain
mechanism) here recently.  You can find the version to be subject of that
discussion at <http://PointedEars.de/scripts/test/map.js>.  Especially
kangax has provided useful advice in the thread that has been incorporated
in the local version.

Looks interesting, I'll dig into it as time permits, thanks.