Closed Bug 70879 Opened 24 years ago Closed 21 years ago

JavaScript 1.5 Reference - boolean

Categories

(Documentation Graveyard :: Web Developer, defect, P2)

Product:
Documentation Graveyard
Component:
Web Developer
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: WeirdAl, Assigned: bc)

References

(
URL
)

Details

Attachments

(2 files)

uneval() versus toSource(), with new Object() modifiers
1.26 KB, text/html
Details
test case
2.37 KB, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 95)
BuildID:    

In the JavaScript1.5 Client-Side Reference, the Boolean() object page is 
contradicting itself.  In this example, the article states:
 
x = new Boolean(false);
if(x) //the condition is true 
 
However, further down the page, the article states the following:
 
The following examples create Boolean objects with an initial value of false: 
bNoParam = new Boolean()
bZero = new Boolean(0)
bNull = new Boolean(null)
bEmptyString = new Boolean("")
bfalse = new Boolean(false)

Only one of these can be correct.  According to ECMAScript 3rd edition and NN6, 
the latter appears to be correct.  I have also verified this inconsistency in 
JSRef1.3 in the Boolean article...

Reproducible: Always
Steps to Reproduce:
1.  Look at the page.  First part under "Description", second part 
under "Examples".  (JSRef1.5)

Mozilla returns false for javascript:x = new Boolean(false);alert(x)

As directed by Mr. Rudman, I am posting the bug here and assigning it to him.
Status: NEW → ASSIGNED
Priority: -- → P2
Summary: JSRef1.5: contradiction in new Boolean(false) → Errors in JavaScript 1.5 documentation
Accepting bug. Changing summary so that this bug tracks all known errors in JS 
doc (on the assumption that there are a collection of bugs that apply to the 
doc, but not an overwhelming number).
More errata discovered:

(1) Date().setFullYear(yearValue[, monthValue, dayValue])

should read:

Date().setFullYear(yearValue[, monthValue[, dayValue]])

The dayValue argument is optional even if a monthValue argument is provided.

Similarly:

Date().setHours(hoursValue[, minutesValue[, secondsValue[, msValue]]]) 
Date().setMinutes(minutesValue[, secondsValue[, msValue]]) 
Date().setUTCFullYear(yearValue[, monthValue[, dayValue]]) 
Date().setUTCHours(hoursValue[, minutesValue[, secondsValue[, msValue]]]) 
	// note:  the method above in the syntax example is spelled setUTCHour
Date().setUTCMinutes(minutesValue[, secondsValue[, msValue]])
Date.UTC(year, month, day[, hrs[, min[, sec[, ms]]]]) 

(2) Object() page does not include documentation on:
	Object.__proto__ (some documentation in JSGuide)
	Object().propertyIsEnumerable
	Object().isPrototypeOf
	Object().hasOwnProperty
	Object().toLocaleString

(3) Date() page has inconsistent font formatting (minor, but noticeable) in the 
methods link list.

(4) Date() page setMinutes link points to getSeconds target.

(5) JS1.3:  Function.caller replaced arguments.caller.  Deprecated again in 
JS1.5.

(6) Possible bug in JS1.5Guide, Chapter 8.  Follow the procedure below:
function myFunc() {
        }
myFunc.prototype = new Array()
var k = new myFunc()
alert(k.constructor)

Expected:  An alert containing myFunc function
Actual:  An alert containing Array function

Uncertain if this is a bug in the docs or against the engine.  Docs give no 
indication this should happen.  Developer can fix this by adding a line:

myFunc.prototype.constructor = myFunc

(7) Date().toLocaleString() overrides Object().toLocaleString(); there is no 
mention of this in the Date().toLocaleString() section.

(8) Date() object page does not include documentation on:
	Date().toLocaleTimeString()
	Date().toLocaleDateString()

(9) ECMAScript specifies toDateString() and toTimeString() methods for the 
Date() object -- these do not appear to exist in NN6.  Possibly a bug against 
JSENG in this respect.

(10) Object() page getters and setters page uses a command-line prompt example. 
 Although the page says these features are only available in the C++ 
implementation of JavaScript (read:  NN6), said implementation doesn't appear to 
have a command-line prompt interface natively, except possibly through the 
JavaScript Console.

Recommend contributors to this bug summary refer to the initial bug report 
subject as (0).
Phil, can you take a look and confirm these bugs? 
Further notes on (6):  The intent is to allow objects to descend from 
constructors besides Object, and inherit prototyping correctly.  The fix I've 
given doesn't quite work correctly in extending prototyping.  I've created a 
quickie JS function to give a true fix.

function Object_newJSPrototype() {
   var typeclass = arguments[0] || this.baseclass || Object
   var response = new typeclass()
   var property
   var OLoop
   for (property in this) {
      eval("response."+property+" = this."+property)
      }
   var nJSP = 
["constructor", "prototype", "__proto__", "toSource", "toString", "valueOf", "wa
tch", "unwatch"]
   for (OLoop = 0; OLoop < nJSP.length; OLoop++) {
      if (eval("this."+nJSP[OLoop]+" != Object.prototype."+nJSP[OLoop])) {
         eval("response."+nJSP[OLoop]+" = this."+nJSP[OLoop])
         }
      }
   return response
   }
Object.prototype.newJSPrototype = Object_newJSPrototype

This function lets me specify a constructor function as the typeclass, and pass 
along the intended prototyped properties correctly.  An example of use:

function Middle() {
   var response = this.newJSPrototype(Array)
   response[0] = 3
   return response
   }

function Middle_toString() {
   return this.join("*")
   }
Middle.prototype.toString = Middle_toString
Correction:  the "__proto__" element should be taken out.  Sorry -- operating 
from old copy.
A quick comment on (5) above: 

function.caller has been put back in JS1.5 as a result of bug 65683. 
arguments.caller will not be put back: see bug 71190.
A comment on (6) above: this is not a bug in JS -


>  function myFunc() 
>  {
>  }
>  myFunc.prototype = new Array();
>  var k = new myFunc();
>  alert(k.constructor);

>  Expected: An alert containing myFunc function
>  Actual:   An alert containing Array function



JS is correct in alerting the Array function. The constructor property 
is not held in the object instance k itself, but in its prototype. 
The following algorithm is used to determine k.constructor:


1. Try to look up "constructor" among k's own properties. It will not be found
   (unless you yourself have created such a property)

2. Try to look up "constructor" among the properties of k's prototype 
   (That is,  k.__proto__ ==  myFunc.prototype). If not, check the next proto.

3. Return the value of constructor when it is finally found..
   (I think it's on k.__proto__.__proto__ )



Thus when you did this above: 

                 myFunc.prototype = new Array();

therefore
                 k.__proto__ ==  new Array();

Thus according to the algorithm, it is correct that
                       
                 k.constructor = function Array()



The key to all this is that the constructor property is not held in k itself.
To verify this, check 

                 k.hasOwnProperty('constructor')
  

This will return 'false', indicating that the constructor property is
actually held up on the prototype chain.


Whenever you change the prototype of a function, watch out!!! 
All properties held on the prototype chain are going to change along with it. 
The constructor property is one of them. In _Javascript: The Definitive Guide_ , 
by David Flanagan (O’Reilly 1998), the author warns about this on pp. 147-148.

A comment on (9) above. You're right, these methods were missing from JS1.5:

                         Date.toDateString()
                         Date.toTimeString()


See bug 58007. They should exist now...otherwise we need to reopen that bug.
I'm seeing them in N6 if I type this in the URL bar: 


javascript:d=new Date();alert(d+ '\n'+ d.toDateString()+ '\n'+ d.toTimeString(); 
                                                                                                     
Oops - missing a final ")" sign the for the alert() above... 

Anyway, if you try this command in NN4.7 you will get an error, because 
the Date methods in question did not exist. But in N6, they do -
Notes on (6):  acknowledged, thanks.  I wasn't sure if it was against the docs 
or against the engine.  The docs do not appear to give any indication you 
cannot descend from Array.

Notes on (9):  This is the exact URL I fed NN6 on Win95:

javascript:d=new Date();alert(d+ '\n'+ d.toDateString()+ '\n'+ d.toTimeString())

The browser did not return an alert.  The JavaScript Console returned this 
message:

Error: d.toDateString is not a function
Source file:
Line:0             Column: 0

My build #, if it helps, is Mozilla/5.0 (Windows; U; Win95; en-US; m18) 
Gecko/20001108 Netscape6/6.0 .

From the bug referenced above for (9), it seems this fix was targeted for 6.01, 
which I do not have.  Did that fix land in 6.01?

Notes on (5):  The following two URLs returned "undefined" in my browser:

javascript:function x() {y()};function y() {alert(arguments.callee.caller)};x()
javascript:function x() {y()};function y() {alert(y.caller)};x()

The following threw an exception: "caller is not defined"

javascript:function x() {y()};function y() {alert(caller)};x()

I expected this last one.  Again, did this land in NN6.01?

I don't wish to create the impression that I'm griping about bugs in NN6; I'm 
griping about inconsistencies in the docs.  I appreciate your feedback, though, 
in clarifying these issues so far.  The browser's great; I'm just trying to 
help out in the docs any way I can.
ajvincent@hotmail.com : Your reports are very accurate and valuable! 
Contributors like you make a difference by uncovering bugs that we miss. 


The points you make in (5) and (9) are entirely accurate as of the 
date of the build you indicate: 

>  My build #, if it helps, is Mozilla/5.0 (Windows; U; Win95; en-US; m18) 
>  Gecko/20001108 Netscape6/6.0 .


The bugs in (5) and (9) were fixed after that build date. New builds 
are actually made every day, and can be downloaded from our ftp sites. 
See:

  http://www.mozilla.org/download-mozilla.html (general download info)
  http://www.mozilla.org/binaries.html         (where the nightly binaries are)


If you have any problems getting them, please email me directly 
and I will help. Another good link to know is: 

  http://www.mozillazine.org/build_comments


Here you will find known improvements/problems with the daily binaries 
as they come out - 

Still more discrepancies in JS1.5Ref:

(11) RegExp.compile, RegExp.test are in NN6, documented in JS1.3Ref, not
documented in JS1.5Ref.

(12) Error object constructor function is totally undocumented by Netscape.
Many thanks to nobody@mozilla.org for that one, and for sending me to the
ECMAScript specs to guess.

(13) RegExp.$x (where isNaN(x)) properties are not entirely clear on use via
documentation in JS1.3 or JS1.5.  Their spelled-out properties are clear.
Notes on (10):

A friend of mine recently pointed out this page to me.  Gives a good quick
example in JavaScript language of usage for getters and setters, among other things.

http://webfx.eae.net/dhtml/mozInnerHTML/mozInnerHtml.html

This site is very good! Thanks!!!
Notes on (10):

Oops -- in testing the code from the above link, I found out the getter and 
setter usage had been deprecated.  A recent discussion between me and Mr. 
Martin Honnen resolved this issue, telling me the official syntax.

The newsgroup is netscape.devs-javascript.  The thread name is "NN6 Getters and 
setters:  correct use?"

There is an updated link (I don't have it in front of me) which uses the 
correct syntax.  It's on the same webhost.
Discrepancy in JS1.3Ref:

(14) setTimeout does not allow the use of the word "this" as an argument.  This
fact, through the documentation, is not immediately obvious to the developer;
the section on setTimeout in JS1.3Ref makes no mention about it.  You can't even
say:

setTimeout("funcName(this)",0)

The trouble is caused simply by the current function being allowed to end and
destroy any reference to the this object.  I have spent two years racking my
brains for a workaround to this little problem, and thanks to Mr. Schwartau's
help on invalid bug # 83784, I have solved it in a script of about 15 lines. 
The result I will submit to JSLib at MozDev very shortly.  (Is anyone interested
in seeing the script anyway?)

Similar troubles exist for setInterval. 
Alex, this bug is for 1.5 documentation errors. If the problem you describe is
relevant for JS 1.3 only, please open a different bug. Thanks.
Noted.

(15) uneval() top-level function is totally undocumented.  Thanks again, nobody.
 Because it's not in ECMAScript, I have to go on word of mouth.

There is no documentation on this function in the JSRef1.5 docs or at
mozilla.org (I did a search for "uneval" at mozilla.org/search.html.)  Bugzilla
itself has only a couple somewhat obscure references to it...
I can take this if you want to assign it to me.
Bob: thanks! Reassigning -
Assignee: rudman → bc
Status: ASSIGNED → NEW
Attached file test case — 
I am making this bug solely about the boolean issues. Any other issues should
be filed as separate bugs with clear statements as to exact error in the
reference or guide. Assign all JS 1.5 documentation bugs to me.

javascript:x = new Boolean(false);alert(x) will alert false 

however 

javascript:x = new Boolean(false);  if (x) alert('true'); else alert('false');

will alert true. This is the distinction that they are trying to make in the
reference.
update url and summary
URL: http://devedge.netscape.com/docs/manu... → http://devedge.netscape.com/library/m...
Status: NEW → ASSIGNED
Summary: Errors in JavaScript 1.5 documentation → JavaScript 1.5 Reference - boolean
Blocks: 206365
Blocks: 206366
date issue forked into bug 206368
No longer blocks: 206365
Phil, The current version of the Boolean documentation is at:

http://elwood.netscape.com:10050/library/manuals/2000/javascript/1.5/reference/boolean.html#1193137

I believe this is (restricted to the Boolean issue), invalid since they are
discussing value vs conditional tests which I believe are accurate.

-> INVALID, please reopen if you disagree
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Reopening on the Boolean issue, because there is a contradiction between
the two indicated lines below:

PARAGRAPH A
-----------
If you specify any object, including a Boolean object whose value is false,
as the initial value of a Boolean object, the new Boolean object has a value
of true.

myFalse=new Boolean(false)   // initial value of true <<<------- COMPARE BELOW
g=new Boolean(myFalse)       //initial value of true
myString=new String("Hello") // string object
s=new Boolean(myString)      //initial value of true

Do not use a Boolean object in place of a Boolean primitive. 
-----------


PARAGRAPH B
-----------
Examples
The following examples create Boolean objects with an initial value of false:

bNoParam = new Boolean()
bZero = new Boolean(0)
bNull = new Boolean(null)
bEmptyString = new Boolean("")
bfalse = new Boolean(false) <<<-------------------------- COMPARE ABOVE

The following examples create Boolean objects with an initial value of true:

btrue = new Boolean(true)
btrueString = new Boolean("true")
bfalseString = new Boolean("false")
bSuLin = new Boolean("Su Lin")
-----------


The two indicated lines each use the construct |new Boolean(false)|;
yet make opposite claims about its initial value. I think by 'initial value'
they mean the return value of the valueOf() method.

Since valueOf() returns 'false' on (new Boolean(false)), I think the
first indicated line is incorrect and needs to be changed to 'false'.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Thanks. changes made to elwood. Will mark fixed when this goes out Friday.
Status: REOPENED → ASSIGNED
f
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Verified Fixed -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: