Talk:Sandbox:JS:String

From MDC

This page already exists. I think the plan is to move all Core_JavaScript_1.5._Reference:* pages to JS:* I've specifically stayed out of that section because I don't know what's going to happen to the organization. --Jonnyq 06:26, 20 October 2005 (PDT)

I meant this to be Sandbox:JS:String. Oops. I'm just playing around with the layout of that page. Once I'm done, I'll cut & paste it to Core_JavaScript_1.5_Reference:Global_Objects:String, then move that to JS:String. --Maian 06:32, 20 October 2005 (PDT)

I think the number conversion part of the article is incorrect. Not that I carefully read the spec, but where did you get the second condition ("number of digits not including those of leading and trailing 0s ...") - only the value of n, that is the exponent, affects the choice between normal and exponential formatting. Second, step 5 ('depending on the sign, "+" or "-"') and step 1 ('if negative, "-"') seem redundant. --Nickolay 13:23, 29 October 2005 (PDT)

I didn't exactly test that part out but I inferred that from the spec: ToString Applied to the Number Type. Hmm...after rereading it, the spec says that nowhere and the "absolute value is between 10^-6 and 10^21" condition already makes it redundant. Also, steps 1 and 5 aren't redundant. They specify that a positive mantissa doesn't have a "+" prefix, while the exponent always has a sign prefix. --Maian 18:42, 30 October 2005 (PST)

Oops, for the exponent I meant to made another comment. It's certainly isn't redundant, but it's not clear that the "depending on the sign" phrase refers to the sign of the logarithm. --Nickolay 03:08, 31 October 2005 (PST)

Ah, I see. I'll clarify that. --Maian 03:32, 31 October 2005 (PST)

[from email]
1) While it makes sense to me to document the methods of an object of a particular type at JS:Obj.prototype.method pages, I'm not sure about pages like JS:String.prototype.length (i.e. properties of object of a particular type). Maybe it should instead be, say, on JS:String:length, with JS:String.prototype.length and JS:String.length redirecting there (even though String.length means a different thing in JS)? Same for JS:Object:__proto__.

String.[prop] will always redirect to String.prototype.[prop] (or will once I add those redirects). --Maian 18:42, 30 October 2005 (PST)

ok, but the point was that describing a property of an instance at a String.prototype.length might seem strange (although I'm not sure). --Nickolay 03:08, 31 October 2005 (PST)

(See my answer below) --Maian 03:32, 31 October 2005 (PST)

2) I added "String." to the "static" properties, e.g. "String.fromCharCode" instead of just "fromCharCode" to make them easier to see. I don't like the name 'static' very much. Perhaps the more wordy "Properties of the String object"?

That sounds better. --Maian 18:42, 30 October 2005 (PST)

You used Properties of the String constructor instead. I don't like it much, because while it's a property of String, and String is a function that can be used as a constructor, semantically the properties are not of the constructor, but rather of the object, which happens to be a constructor. --Nickolay 03:08, 31 October 2005 (PST)

It's just that the term "String object" is ambiguous. It either refers to the String constructor/function are an object created by the String constructor. It's not like we can just redefine the term either, since JS authors use the term this way. This applies to all constructors BTW, even user-defined ones, e.g. a Car constructor creates a Car object, yet the constructor itself is also called the Car object. The problem in a nutshell is C++/Java terminology thrust upon a language whose "classes" are objects. I'm not sure what can be done about this. We can try to stick with the term "String instance" to differentiate from "String object", but since so many pages currently use "String object" inconsistently and would have to be changed, that's going to be a hassle. --Maian 03:32, 31 October 2005 (PST)

I've decided that I'll use "string object" (uncapitalized) to refer to objects instanstiated by the String constructor, and "the String object" (capitalized and always has the article "the") for the constructor itself. --Maian 00:44, 18 November 2005 (PST)

Perhaps, "the String object" ("String" is wrapped in <code> tags)? --Nickolay 02:30, 18 November 2005 (PST)

Yeah, that's what I meant :) --Maian 03:04, 18 November 2005 (PST)

3) I think it's worth mentioning that the String constructor and the String function is the same object, used in different contexts.

I'm just not sure where to say that, the function or the object section? Hmm... --Maian 18:42, 30 October 2005 (PST)

4) you mention that string primitives are immutable, but in JS the strings themselves (i.e. objects too) are immutable, as I understand it. Therefore, I would mention that somewhere and remove the 'individual characters cannot be set' example.

Depends on what you mean immutable. JS objects are always (with maybe some exceptions) mutable in the sense that the object's properties can be changed. After all, that's what an object is: a collection of properties. Now, it is true that the String object's internal reference to the string primitive can't be changed. I'll mention that somewhere. --Maian 18:42, 30 October 2005 (PST)

5) the Typecast operation section: I think that mentioning ToString isn't necessary. See also the talk page.

I only mentioned ToString so I could use "ToString(object.toString())" for the object-to-string row. --Maian 18:42, 30 October 2005 (PST)

Right, and I think the page became better after it's been removed :) --Nickolay 03:08, 31 October 2005 (PST)

6) the eval(new String("2+2")) example could be shortened to a single (the only counter-intuitive) line.

Agreed. --Maian 18:42, 30 October 2005 (PST)

--Nickolay 10/29/2005