Code Guidelines

[Asen Bozhilov]

If you still wanna to write this as a rule, please mentioned, that
it's not the rule, but *just your own suggestion and own meaning*,
meanwhile other people can choose different (good) way augmenting
object and write in OOP-style such as `string.capitalize()' instead of
long ugly `Ext.util.Format.capitalize(string)'. Especially in own
project.

You are absolutely right, but augmentation Object.prototype can be
harmful and confused. If implementations use native object produced
via `new Object()` as a VO and internal [[Prototype]] refer
Object.prototype, any augmentation of `object' referred from
Object.prototype can be harmful and confused. See below:

Object.prototype.x = 10;
var x = null;
(function()
{
window.alert(x);
}());

Expected value of `x` is `null`, but if VO is implement as a native
object value of `x` will be 10. Because:

| 10.1.4 Scope Chain and Identifier Resolution
| 1. Get the next object in the scope chain.
| If there isn't one, go to step 5.

In that case next object is VO/AO associated with EC created from
anonymous function.

| 2. Call the [[HasProperty]] method of Result(1),
| passing the Identifier as the property.

[[HasProperty]] lookup in prototype chain and will be return `true` in
that case.

| 3. If Result(2) is true, return a value of type Reference
| whose base object is Result(1) and whose property name
| is the Identifier.

{base : VO, propertyName : x};

So in my case *expected* value is primitive number value 10.

See and next example in Firefox 3.5:

Object.prototype.x = 10;
(function()
{
window.alert(x); //10 expected ReferenceError
}());

window.alert(this instanceof Object); //false
window.alert(this.__proto__ === Object.prototype); //false

How it is implement Global Object in Firefox 3.5? We can see Global
Object does not refer from internal [[Prototype]] object referred from
Object.prototype. And we can see that `object' doesn't inherit in
explicit way from Object.prototype. The question is, how it is
implement that object?

Regards.

 

[Thomas 'PointedEars' Lahn]

RobG wrote:
Garrett Smith wrote:
Replace: "</" + "script>"
with: "<\/script>";
Replace: "</td>";
with: "<\/td>";

I don't understand the issue here, is it specifically with the TD end
tag? Or is it more generally with end tags in HTML sent as an XHR
response?

No, it refers to markup in script (e.g. document.write calls). [...]
Nothing to do with the tag type.

The *what*? I thought this was comp.lang.javascript, not
alt.scriptkiddie.misc.

The type of tag serialized in the string (e.g. TD vs. SCRIPT). Are
you proposing to refer to these as *elements*?

TD is one *element* type, SCRIPT is another.

I think not as we are talking about just one (ending) tag (not both).

Iff you had meant "tag type" to distinguish between start tags and *end*
tags, which AIUI you have not, then that would have been acceptable. The
term would be potentially unclear, though.


PointedEars

 

[Dmitry A. Soshnikov]

If you still wanna to write this as a rule, please mentioned, that
it's not the rule, but *just your own suggestion and own meaning*,
meanwhile other people can choose different (good) way augmenting
object and write in OOP-style such as `string.capitalize()' instead of
long ugly `Ext.util.Format.capitalize(string)'. Especially in own
project.

You are absolutely right, but augmentation Object.prototype can be
harmful and confused. If implementations use native object produced
via `new Object()` as a VO and internal [[Prototype]] refer
Object.prototype, any augmentation of `object' referred from
Object.prototype can be harmful and confused. See below:

Object.prototype.x = 10;
var x = null;
(function()
{
  window.alert(x);

}());

Expected value of `x` is `null`, but if VO is implement as a native
object value of `x` will be 10. Because:

| 10.1.4 Scope Chain and Identifier Resolution
| 1. Get the next object in the scope chain.
| If there isn't one, go to step 5.

In that case next object is VO/AO associated with EC created from
anonymous function.

| 2. Call the [[HasProperty]] method of Result(1),
| passing the Identifier as the property.

[[HasProperty]] lookup in prototype chain and will be return `true` in
that case.

| 3. If Result(2) is true, return a value of type Reference
| whose base object is Result(1) and whose property name
| is the Identifier.

{base : VO, propertyName : x};

So in my case *expected* value is primitive number value 10.

See and next example in Firefox 3.5:

Object.prototype.x = 10;
(function()
{
  window.alert(x); //10 expected ReferenceError

}());

Thanks Asen, I appreciate your detailed explanations to me, although,
I sure know all of this I mentioned that in my articles about scope
chain (chapter 4) and functions (chapter 5). It's sure well known fact
that in some versions of Spidermonkey Global object has
`Object.prototype' in it's prototype chain. Moreover, as you know,
special object created for NFE (named function expression) also
inherits (and fairly - by the ECMA-262-3) from the `Object.prototype'.
This situation is also taking place in Blackberry implementation,
where even simple activation object can inherit from
`Object.prototype'.

But if you carefully I mentioned it myself in link I gave above in
previous post. And till we haven't control of {DontEnum} (in
ECMA-262-5 - [[Enumerable]]), augmenting of `Object.prototype' as a
bad idea goes without saying and there's no reason to mention that
explicitly

window.alert(this instanceof Object); //false
window.alert(this.__proto__ === Object.prototype); //false

How it is implement Global Object in Firefox 3.5? We can see Global
Object does not refer from internal [[Prototype]] object referred from
Object.prototype. And we can see that `object' doesn't inherit in
explicit way from Object.prototype. The question is, how it is
implement that object?

I've already mentioned about that: <URL:
http://groups.google.ru/group/comp....73/cea80a0fa53df9b0?hl=en&q=#52cce62f81fae1e6>

So the prototype chain of the Global in FF is the following (where
Object.prototype sure is):

// [xpconnect wrapped native prototype]
alert(this.__proto__);

// [object Global Scope Polluter]
alert(this.__proto__.__proto__);

// [object Object] - Object.prototype appears only now
alert(this.__proto__.__proto__.__proto__);

// null, end of the chain - Object.prototype.[[Prototype]]
alert(this.__proto__.__proto__.__proto__.__proto__);

/ds

 

[David Mark]

David Mark wrote:
RobG wrote:
Garrett Smith wrote:
Replace: "</" + "script>"
with:    "<\/script>";
Replace: "</td>";
with:    "<\/td>";
I don't understand the issue here, is it specifically with the TD end
tag? Or is it more generally with end tags in HTML sent as an XHR
response?
No, it refers to markup in script (e.g. document.write calls).
[...]
Nothing to do with the tag type.
The *what*?  I thought this was comp.lang.javascript, not
alt.scriptkiddie.misc.

The type of tag serialized in the string (e.g. TD vs. SCRIPT).  Are
you proposing to refer to these as *elements*?

TD is one *element* type, SCRIPT is another.

<http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1>

Are you kidding?

Iff you had meant "tag type" to distinguish between start tags and *end*
tags, which AIUI you have not, then that would have been acceptable.

As you understand what? Was my explanation unclear?

The
term would be potentially unclear, though.

I don't think so in this case.

 

[Eric Bednarz]

Garrett Smith <[email protected]> writes:

[...]

Well, that didn’t take long. The document type declaration *is part of
the prolog*, in both XML and SGML productions.

Maybe so, but for HTML, no comments and no prolog will trigger
quirks mode in IE. They should both be avoided for this reason.

Correction:
"comments and/or prolog will trigger quirks mode in IE."

Read again what I wrote. Without a prolog, you trigger quirks
mode. There is no “and/or†involved either, as comment declarations
preceding the document instance set are part of the prolog as well.

When you write

| * Use standards mode, with DOCTYPE first (no comment, xml prolog).

you probably mean “no XML declarationâ€. ‘Prolog’ is clearly defined by
XML 1.0, and it’s not what you want it to be.

(I can live with the term ‘comment’ in a practical HTML context, but
when pretending that it is useful to validate a HTML document against
its document type declaration subset, SGMLese should be used throughout
an ‘comment declaration’ would be correct.)

 

[Garrett Smith]

[snip]

"Don't modify objects you don't own".

[...]


Just to be fair, you should mention, that augmenting (build-in, any)
objects in dynamic language with mutable objects - is in ideology of
such language. So, everyone chooses. You can *suggest* do not
augmenting "not own" object (with providing serious reason, which is
still just your meaning), but not statement this as rule.

For do not repeat myself: <URL:
http://groups.google.ru/group/comp....64462/bbfb83eb82ef9b41?hl=en#bbfb83eb82ef9b41>
and there's also link to other similar topic.

The only (the only.) reason - is using 3rd-party code, combined in
your application. But from this point of you, what exactly you are
afraid of - "another piece of code may create a different
Element.prototype.hide" - with the same success "another piece of code
may create a different hideElement( el )" which you suggest as a
"workaround", there's no any difference.

For public API, a global hideElement would not be a good interface.
Instead, the interface would best be defined somewhere else.

When the method name is clearly defined as a property of an object, such as:

AcmeWidgets.dom.hideElement.

If the file "dom" is defined, say "dom.js", it would be clear what
depends on it.

If, OTOH, a public API that modifies built ins does not draw dependency
lines. Everything depends on everything. A public library that modifies
the built-ins can't really be trusted to work with other code.

// Where does this method belong? hostElementExtensions.js, or?
Element.prototype.hideElement -

Two different libraries could potentially define an
AcmeWidgets.dom.hideElement, but that would be explicit and immediately
obvious.

So, again, it's absolutely normal to augmenting objects in ES,
providing good documentation of what have you augmented (and for whole
code in general).

If you still wanna to write this as a rule, please mentioned, that
it's not the rule, but *just your own suggestion and own meaning*,
meanwhile other people can choose different (good) way augmenting
object and write in OOP-style such as `string.capitalize()' instead of
long ugly `Ext.util.Format.capitalize(string)'. Especially in own
project.

I do not agree that util is a good name for a package. Packages or units
of code should be organized by usage pattern.

"util" is a kitchen sink.

 

[Dmitry A. Soshnikov]

[snip]

A public library that modifies
the built-ins can't really be trusted to work with other code.

I understand, and told myself, that's this is the only (again - the
only.) reason. And from this point of view, you should mention this
just as a warning for authors of libraries, but not as a rule for
programming on ECMAScript.

Augmenting of built-ins is kind of additional "plug-ins", additional
functionality, which is treated as *own* which provides the way to
write more clear and elegant code. Just like host environment provides
additional objects to complete the program state, your augmenting
provides additional functionality.

There's no difference from the functional point of view - will you put
this code into the prototype of the built-in object, or will define
some global (or in your own namespace) function. But from the
ideological point of view, difference *is*.

And repeat, that dozen of 3rd-party, all of them (all of them!) can
provide the same global function `hideElement' and cause the name
conflict.

So, - only just a suggestion or a warning, but not the rule, 'cause
that's ECMAScript, but not a some static language. And for me, it's a
good practice to put functionality there where it's place (e.g. `trim'
or `capitalize' for strings in the String.prototype).

I do not agree that util is a good name for a package. Packages or units
of code should be organized by usage pattern.

"util" is a kitchen sink.

That's not mine, that's real example from ExtJS library. I mentioned
that to show how the code can converts into the overloaded massive
long lines using everywhere things such as procedure-like style
`Ext.util.Format.capitalize(string)'. Yeah, influence of Java is
conclusive in ExtJS library

/ds

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Sat, 26 Dec 2009 14:47:43, Garrett Smith

It may be worth considering assigning priority labels to certain things.
For example: "Use valid HTML" an "Use standards mode" would be priority
1 guidelines, while "Use efficient string concatenation techniques"
might be a Priority 2, while

Much less than Priority 2, unless you can show a reasonable proportion
of common practical cases where optimising concatenation makes a
noticeable (not a measurable) difference to the time seen between
initiating action and visible results.

Functions that return multiple type provide more variance to the caller.

Sometimes this happens on accident, where the function was
intended to return one type, but can return a value of a different type.

Functions that return only one value type (including undefined) do not
burden the caller with having to check the return type.

It is something to look for in code where the function may, for example,
return a number in one case and a string in another case.

Functions that return multiple type have their place. A method might
return an object, but return null if the operation failed. So it is not
a rule, but something to consider when looking the code.

One does not need to check the return type if the mutually exclusive
return alternatives are to give something which will pass as false and
to give something which will not pass as false.

Result = FunctionOfAllSortsOfThings(......)
if (!Result) { ... /* it failed */ ... ; return }
// Code using good Result ...

Result = FunctionOfAllSortsOfThings(......)
if (Result) { /* Code using good Result */ ; return Answer }
// moaning & wailing

For an example, see
FAQ 4.2 How can I create a Date object from a String?

OTOH, my recently-posted Leading Zero function LZ takes care always to
return a string (unlike function LZ(N) { return N<10 ? "0" + N : N } );
then Y+LZ(M)+LZ(D) works as well for Oct-Dec as it does for Jan-Sep.


Really, the recommendation should be against functions returning
unexpected types.

SRP The Single Responsibility Principle
A class should have one, and only one, reason to change.
OCP The Open Closed Principle
You should be able to extend a classes behavior, without modifying it.
LSP The Liskov Substitution Principle
Derived classes must be substitutable for their base classes.
DIP The Dependency Inversion Principle
Depend on abstractions, not on concretions.
ISP The Interface Segregation Principle
Make fine grained interfaces that are client specific.

TMA.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
RobG wrote:
Garrett Smith wrote:
Replace: "</" + "script>"
with: "<\/script>";
Replace: "</td>";
with: "<\/td>";

I don't understand the issue here, is it specifically with the TD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
end tag? Or is it more generally with end tags in HTML sent as an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
XHR response?
No, it refers to markup in script (e.g. document.write calls).
[...]
Nothing to do with the tag type. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The *what*? I thought this was comp.lang.javascript, not
alt.scriptkiddie.misc.
The type of tag serialized in the string (e.g. TD vs. SCRIPT). Are ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
you proposing to refer to these as *elements*?

TD is one *element* type, SCRIPT is another.

<http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1>

Are you kidding?

No. Have you read that part of the Specification carefully?

As you understand what?

You were referring to TD and SCRIPT as different "type(s) of tag".

Was my explanation unclear?

It was not only unclear, it was incorrect.


HTH

PointedEars

 

[David Mark]

                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>> >> >> end tag? Or is it more generally with end tags in HTML sent as an

         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>> >> >> XHR response?

No, it refers to markup in script (e.g. document.write calls).
[...]
Nothing to do with the tag type.

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>> >> The *what*?  I thought this was comp.lang.javascript, not
         ^^^^^^^^^^^                           ^^^^^^^^^^^^^^^^^^

Are you kidding?

No.  Have you read that part of the Specification carefully?

No need.

You were referring to TD and SCRIPT as different "type(s) of tag".

You misunderstand. They are different "types of tags" (as only the
ending tags of each are present in the serialization). If I had meant
element, I should have said element.

 

[Garrett Smith]

If you still wanna to write this as a rule, please mentioned, that
it's not the rule, but *just your own suggestion and own meaning*,
meanwhile other people can choose different (good) way augmenting
object and write in OOP-style such as `string.capitalize()' instead of
long ugly `Ext.util.Format.capitalize(string)'. Especially in own
project.

You are absolutely right, but augmentation Object.prototype can be
harmful and confused. If implementations use native object produced
via `new Object()` as a VO and internal [[Prototype]] refer
Object.prototype, any augmentation of `object' referred from
Object.prototype can be harmful and confused. See below:

Object.prototype.x = 10;
var x = null;
(function()
{
window.alert(x);
}());

......^

Move that paren inwards, to group the FunctionExpression, as:
(function(){})();

Expected value of `x` is `null`, but if VO is implement as a native
object value of `x` will be 10. Because:

[...]

If - VO - is a variable object, then it must have no [[Prototype]].

The prototype of teh global object is implementation-dependent.

In Blackberry9000, the activation object has a [[Prototype]]. That is a
severe bug.

The identifier - x - would be resolved on Object.prototype when the
scope chain was augmented "as if by the expression new Object()".

The three cases where this happens:-
1) FunctionExpression with Identifier (NFE)
2) catch clause
3) - with - statement.

(function(){
Object.prototype.x = 10;
var x = null;
with( 1 ) { alert( "with, x: " + x ); }

try {
throw.1;
} catch(ex) {
alert( "with, x: " + x );
}
})();

The issue with NFE and catch clause was observable in Firefox up until
around version 3.1.

Firefox 3.5:-
"with, x: 10"
"catch, x: null"

 

[Garrett Smith]

[snip]

A public library that modifies
the built-ins can't really be trusted to work with other code.

I understand, and told myself, that's this is the only (again - the
only.) reason. And from this point of view, you should mention this
just as a warning for authors of libraries, but not as a rule for
programming on ECMAScript.

[...]

What I have as draft includes most of what I wrote in the last message.
The advice to create a top-level function advise creating a method as a
member of the global object, having the same problems.

Instead, a separate interface should be created. The interface should be
clearly defined, cohesive, and unlikely to conflict with other objects
that use the system.

You can do that, but it doesn't fit what I think of as OOP. It is an
abstraction using inheritance, but it lacks encapsulation and modularity.

It is more like a reverse-inheritance type of scheme that changes String
in a way that may or may not be forwards-compatible. Object.create, for
a coincidental example, is now a built-in method, but exists as a
user-defined method in some codebases.

That's not mine, that's real example from ExtJS library. I mentioned
that to show how the code can converts into the overloaded massive
long lines using everywhere things such as procedure-like style
`Ext.util.Format.capitalize(string)'. Yeah, influence of Java is
conclusive in ExtJS library

Util is not a descriptive package name.

Not for Java, and not for Ext.js.

Take a look at java.util and please tell me Date have to do with Arrays
or TimerTask? Nothing, right?

Well javascript borrowed from Java, too. We've got the poor Date class
and Math. Many of the Math properties could have been moved to Number
and/or Number.prototype, depending on the property. Math.floor could be
Number.prototype.floor(), We could have 3.45.round() instead of
Math.round(3.45). Number.PI, Number.max(10, 11, 12). Well that is all
fiction made up but for me it makes way more sense than having a
separated Math class.

It seems worth considering changing that to Ext.string, and adding the
capitalize method to it.

Ext.string.capitalize("foo");

Collisions to that would be deliberate and you would know right off what
the capitalize method is, where it is defined, and not have to worry who
buggered String.prototype or if the buggering was a dual- action effort
on part of multiple third party libraries.

The capitalize method would not localize consistently, as noted recently
on ES-Discuss[1]. If the string is translated and included literally,
this doesn't occur.

var msg = "${req.msg}";

In ES5, a property can be defined has having [[Writable]] = false.

This can happen in Object.create, with Object.defineProperty, setting
writable: false.

Object.freeze seals an object and makes its properties unmodifiable by
setting [[Writable]] to false.

Creating a sealed object eliminates the possibility for conflicts with
another Ext.string.capitalize.

[1]https://mail.mozilla.org/pipermail/es-discuss/2009-December/010482.html

 

[Dmitry A. Soshnikov]

[snip]

A public library that modifies
the built-ins can't really be trusted to work with other code.

I understand, and told myself, that's this is the only (again - the
only.) reason. And from this point of view, you should mention this
just as a warning for authors of libraries, but not as a rule for
programming on ECMAScript.

[...]

What I have as draft includes most of what I wrote in the last message.
The advice to create a top-level function advise creating a method as a
member of the global object, having the same problems.

Instead, a separate interface should be created. The interface should be
clearly defined, cohesive, and unlikely to conflict with other objects
that use the system.

Formally, there's no full protected "interface" from this point of
view. Will you name it `MyVeryOwnNamespace', and tomorrow, the same
name will be in all `libraries' and in ES itself. So, naming
collisions should not be treated as the main reason.

You can do that, but it doesn't fit what I think of as OOP. It is an
abstraction using inheritance, but it lacks encapsulation and modularity.

What exactly do you mean? Please explain.

It is more like a reverse-inheritance type of scheme that changes String
in a way that may or may not be forwards-compatible. Object.create, for
a coincidental example, is now a built-in method, but exists as a
user-defined method in some codebases.



Util is not a descriptive package name.

Not for Java, and not for Ext.js.

Take a look at java.util and please tell me Date have to do with Arrays
or TimerTask? Nothing, right?

Well javascript borrowed from Java, too. We've got the poor Date class
and Math. Many of the Math properties could have been moved to Number
and/or Number.prototype, depending on the property. Math.floor could be
Number.prototype.floor(), We could have 3.45.round() instead of
Math.round(3.45). Number.PI, Number.max(10, 11, 12). Well that is all
fiction made up but for me it makes way more sense than having a
separated Math class.

Yeah, it could easily be `3.45.round()' instead of `Math' I agree.

It seems worth considering changing that to Ext.string, and adding the
capitalize method to it.

Ext.string.capitalize("foo");

Collisions to that would be deliberate and you would know right off what
the capitalize method is, where it is defined, and not have to worry who
buggered String.prototype or if the buggering was a dual- action effort
on part of multiple third party libraries.

But there's no difference, will somebody put `capitalize' into the
`String.prototype' or will define own `Ext' or `Ext.string' namespace
- tomorrow, it can easily appear in all other libraries and in ES
itself. So, don't use name collision as a reason.

Moreover, I tell, people which use libraries think vice versa - they
think: "we don't not modify String.prototype as we're using 3rd-party
frameword, which can put tomorrow (in the next version) `capitalize'
method into it. So let's make our own namespace such as
OutSuperDuperNamespace.string and put `capitalize' there." And
tomorrow, OMG, that framework provides the same
`OutSuperDuperNamespace' and even `OutSuperDuperNamespace.string'
breaking down all the project. So, that's not the reason.

The capitalize method would not localize consistently, as noted recently
on ES-Discuss[1]. If the string is translated and included literally,
this doesn't occur.

I understand, but that's completely another question, and doesn't
touch the discussing topic.

In ES5, a property can be defined has having [[Writable]] = false.

This can happen in Object.create, with Object.defineProperty, setting
writable: false.

Object.freeze seals an object and makes its properties unmodifiable by
setting [[Writable]] to false.

Creating a sealed object eliminates the possibility for conflicts with
another Ext.string.capitalize.

Yep, thanks, I've also read ES-5 spec already. So, you're moving to
the way I told - better to suggest to use some static language in such
case, but not the language with dynamic mutable objects and statement
as a rule: "Do not touch your own objects".

So, if you'll write something like: "Remember that augmenting built-
ins may cause naming conflicts, bla-bla... but the same can be with
any other name in the program - no matter where it's - in global or in
own namespace" - that's will be normal. It will sound like suggesting
from your own opinion.

But if you'll write - "Augmenting built-ins - is a bad practice" -
that will be categorical and wrong, and I can statement, that person
which spread that not completely understand the goal of dynamic
languages (I do not mean exactly you, I'm telling abstractly now).

/ds

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
RobG wrote:
Garrett Smith wrote:
Replace: "</" + "script>"
with: "<\/script>";
Replace: "</td>";
with: "<\/td>";

I don't understand the issue here, is it specifically ^^^^^^^^^^^^^^^^^^
with the TD end tag? Or is it more generally with end tags ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
in HTML sent as an XHR response? ^^^^^^^
No, it refers to markup in script (e.g. document.write calls).
[...]
Nothing to do with the tag type. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
The type of tag serialized in the string (e.g. TD vs. SCRIPT).

^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^

Are you proposing to refer to these as *elements*?
TD is one *element* type, SCRIPT is another.

<http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1>
Are you kidding?

No. Have you read that part of the Specification carefully?

No need.

Apparently there is.

You misunderstand. They are different "types of tags" (as only the
ending tags of each are present in the serialization). If I had meant
element, I should have said element.

If so, it was easy to misunderstand, as in "potentially unclear".

They are different "types of tags" (as only the
ending tags of each are present in the serialization). If I had meant
element, I should have said element.

So you meant "e.g. </td> vs. </script>" (not "e.g. TD vs. SCRIPT"), and
called the former "type(s) of tags" or "tag type", which is potentially
unclear after all?

For if anything could be called "type of tag" or "tag type", it is the
difference between start tag and end tag, and in that sense both `</td>'
and `</script>' are of the same type. But those who did not know the
correct terminology could, mislead by your statement, assume that what you
call "type of tag" or "tag type" would refer to what is correctly called
the element type.

You garbled the quotations; please learn to quote. (Not using Google
Groups for posting would help a lot there.)


PointedEars

 

[Asen Bozhilov]

Asen Bozhilov wrote:

Move that paren inwards, to group the FunctionExpression, as:
(function(){})();

What is the difference between:

typeof function(){}();

(function(){}());

(function(){})();

Please explain.

Expected value of `x` is `null`, but if VO is implement as a native
object value of `x` will be 10. Because:

[...]

If - VO - is a variable object, then it must have no [[Prototype]].

But documentation permit VO to have [[Prototype]] from:

| 10.1.4 Scope Chain and Identifier Resolution
| 2. Call the [[HasProperty]] method of Result(1), passing the
Identifier as the property.

I don't think that is a bug in Blackberry9000, because documentation
permit that behavior. That is implementation-dependent too.

Btw 1: In FAQ link above "BlackBerry JavaScript Reference"
<URL: http://docs.blackberry.com/en/developers/deliverables/8861/>
Links in that page ares broken. They redirect me to:
<URL: http://docs.blackberry.com/404error.jsp>

Proper URL is:
<URL: http://docs.blackberry.com/en/developers/deliverables/11849/>

Btw 2: Why not include in "Code Guidelines" `delete` operator over a
host objects, because host object can implement own internal
[[Delete]] method and using `delete` operator for host objects can be
error-prone.

Regards.

 

[Lasse Reichstein Nielsen]

What is the difference between:

typeof function(){}();

(function(){}());

(function(){})();

Please explain.

The last two are equivalent. The first evaluates to a string instead
of the undefined value

I would recommend (function(){})() over (function(){}()) for two reasons:
readability (it's easier to see the grouping) and convention (it's easier
to recognize what's going on). There is no technical reason to prefer one
over the other.

/L

 

[Dmitry A. Soshnikov]

The last two are equivalent. The first evaluates to a string instead
of the undefined value

I would recommend (function(){})() over (function(){}()) for two reasons:
readability (it's easier to see the grouping) and convention (it's easier
to recognize what's going on). There is no technical reason to prefer one
over the other.

Meanwhile, there's a test case, when that two forms will not be
equivalent. It's related to automatic semicolon insertion when
semicolon is not inserted in case of one function expression form:

var foo = function () {
alert(arguments[0]);
}

(function () {return 'x';}())

In this case we've "forgot" semicolon after FE referenced by `foo'
variable, try to run it, you'll see the result.

var foo = function () {
alert(arguments[0]);
}

(function () {return 'x';})()

Meanwhile, this form (where we've also "forgot" semicolon after `foo')
will throw an exception.

Sure, this case should be changed to the following with semicolons:

var foo = function () {
alert(arguments[0]);
};

(function () {return 'x';})();

In this form the grouping operator of the second one FE is not treated
as brackets of the call expression, as it was in two previous cases.

/ds

 

[Garrett Smith]

The last two are equivalent. The first evaluates to a string instead
of the undefined value

I would recommend (function(){})() over (function(){}()) for two reasons:
readability (it's easier to see the grouping) and convention (it's easier
to recognize what's going on). There is no technical reason to prefer one
over the other.

Right. All three are valid ExpressionStatement.

I had (mis?)believed a parse error in a browser, and so have always that
approach. I can't create an error by wrapping the entire thing in
parens. Safari 2 is happy with:-

javascript: (function(){alert(1)}());

But it is also important to remember that an ExpressionStatement can't
begin with `function` keyword because that would be ambiguous with a
FunctionDeclaration. Nor can an expression statement begin with `{`, as
that would be ambiguous with a Block, and so:-

(function(){}());

- is valid, but:-

function(){}(); // SyntaxError.

- is not.

 

[Garrett Smith]

Asen Bozhilov wrote:

Move that paren inwards, to group the FunctionExpression, as:
(function(){})();

What is the difference between:

typeof function(){}();

(function(){}());

(function(){})();

Please explain.

Expected value of `x` is `null`, but if VO is implement as a native
object value of `x` will be 10. Because:

[...]

If - VO - is a variable object, then it must have no [[Prototype]].

But documentation permit VO to have [[Prototype]] from:

| 10.1.4 Scope Chain and Identifier Resolution
| 2. Call the [[HasProperty]] method of Result(1), passing the
Identifier as the property.

I don't think that is a bug in Blackberry9000, because documentation
permit that behavior. That is implementation-dependent too.

That actually seems to be correct.

A program cannot access the activation object, but there's nowhere I
read that activation object cannot have a [[Prototype]].

If the variable object has a [[Prototype]], then identifier resolution
behaves differently. We disucssed this before...

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/ec2ffbc979c65cc4/

Can Activation Object have a [[Prototype]]?

I'm posting this question to es-discuss. ES5 has what is called "Lexical
Environment" and I do not know if [[Prototype]] is explicitly forbidden
for that object. Am I missing something?

Btw 1: In FAQ link above "BlackBerry JavaScript Reference"
<URL: http://docs.blackberry.com/en/developers/deliverables/8861/>
Links in that page ares broken. They redirect me to:
<URL: http://docs.blackberry.com/404error.jsp>

Oh, that's no good.

Proper URL is:
<URL: http://docs.blackberry.com/en/developers/deliverables/11849/>

Ah, thanks, fixed locally.

Btw 2: Why not include in "Code Guidelines" `delete` operator over a
host objects, because host object can implement own internal
[[Delete]] method and using `delete` operator for host objects can be
error-prone.

Certainly it can be. IE throws errors with delete on window properties,
though not on global variables.

var x = 10;
this.y = 11;
delete x; // false;
delete y: // error.

 

[Asen Bozhilov]

var foo = function () {
  alert(arguments[0]);

}

(function () {return 'x';})()

Meanwhile, this form (where we've also "forgot" semicolon after `foo')
will throw an exception.

Thank for that example. It can be very hard to catch that, especially
if returned value from `foo` is a reference to object which have
internal [[Call]] method.

var foo = function () {
return arguments[0];
}

(function () {return 'x';})();

Expected behavior in unexpected way.

var foo = function () {
return function(){};
}

(function () {return 'x';})();

There are no error, and absolutely unexpected behavior in first look,
but actually is it normal and expected behavior.