You could extend String.prototype if you wanted to but it's probably one of the less common ways to do this kind of thing. It has disadvantages like portability, and it will ONLY works on strings. Using Number() or + on something that's not a string (undefined, an object, a number) will work fine, but your prototype idea will fail. If you did want to go this way I'd recommend calling it `toNumber` to match the `toString` convention.
On Fri, Feb 24, 2012 at 7:35 AM, Lothar Pfeiler <[email protected]>wrote: > Yes, you're right. I am new to a JS group. So, mixing integers and > floats is a new experience to me. This competition of typing less, was > something I took part in back in the 90s and I thought it's gone > because of the auto completion feature of today's editors. And because > of today's processors and libraries I thought the performance > discussions are gone, too. > > I think the dos and don'ts of a language are more important, which > brings me to my question regarding string-to-integer conversion. > Is it ok to extent the String object for some oo-style? > > e.g.: > String.prototype.intValue = function () { > return parseInt(this, 10); > }; > > var area = width.intValue() * height.intValue(); > > Lothar > > On Feb 23, 8:20 pm, Marco Rogers <[email protected]> wrote: > > You guys should stop trolling each other and try to be helpful. This is > an > > area of js fraught with both FUD and wtfjs. Better to educate than to > spout > > personal anecdotes and one off edge cases. Mark has the right idea by > > saying pick the technique that "does what you want". But you have to know > > the difference in order to do that. And you can't assume that what you > want > > is what everyone always wants. This is an implementation detail. > > > > And finally don't ignore the most obvious and important difference. > > parseInt... parses integers! It will always try to give you back an > > integer. Whatever your value is, you will get an integer or you will get > > NaN. It will try to do this with improperly formatted strings as long as > > they start with a parse-able number, e.g. "100px". This is either a nice > > feature, or something to be avoided, depending on how well you've > validated > > your input. On the other hand, number conversion is part of the standard > > language grammar. It uses well defined (but not necessarily intuitive) > > rules to take a value and give you a number that may or may not have a > > decimal component, or if it can't, it'll give you NaN. But it also > respects > > alternate number formats that are valid like exponential notation, e.g. > > Number("10e2") === 1000. Using the unary "+" operator in front of a value > > is strictly equivalent to calling Number(). > > > > Now, all of that being said, I think it's clear that both of these > violate > > principle of least surprise once you get into edge cases. They will both > > screw you at some point or another if you don't control your input and > > validate your output. So which one you should use isn't an "always" thing > > and it has nothing do with what you find "more readable". Understand them > > both, and pick the one that works for what you're doing. > > > > :Marco > > > > > > > > > > > > > > > > On Wednesday, February 22, 2012 10:18:57 AM UTC-8, Mark Hahn wrote: > > > > > > +'123 px' > > > > NaN > > > > > And that is exactly correct. '123 px' is not a number. Using that > > > "feature" is worse than trusting type coercion. I would never trust > that > > > in my code, just as I always use === instead of ==. Well actually I > use > > > "is" in coffee, but that is a different subject. > > > > > What if your string was accidentally "100%" instead of "100 px"? > > > > > You said nothing is right for me. I'm just pointing out that was an > > > overly broad statement. Using + instead of parseInt *is* exactly > right for > > > me. > > > > > If you want to be able to use '010' to represent 8 and '1xyz' to > represent > > > 1, then more power to you. I myself will never use parseInt. Not > only for > > > the behavior but because it takes too much typing, is less succinct and > > > therefore is less readable. > > > > > Compare... > > > area = +w * +h > > > To ... > > > area = parseInt(w, 10) * parseInt(h, 10) > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
