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
