I don't agree that using the unary plus operator is a best practice for string->number conversions. Best practices should advocate maintainability and clarity - in this case parseFloat is the better choice for obvious reasons. Just be aware that parseFloat and unary + aren't exactly equivalent: parseFloat("10x") === 10, +"10x" === NaN.
And no, JavaScript is not a "non-typed language." AFAIK JavaScript is both dynamically and weakly typed. Being in the latter category does mean that it will implicitly convert values to other types in certain scenarios.
I don't understand why he would recommend unary as a replacement for casting. It obfuscates the intent of your code, which is especially concerning since this reads like a guide for beginners.
That only applies to parseInt because it tries to guess the radix if one isn't supplied. parseFloat assumes base 10 and doesn't accept a radix argument.
I imagine they require the developer account type for the device program, right? That's what the vocabulary on the page seems to imply -- I'm going to try to get the coupon with with a basic account first, but I expect they'll just tell me to upgrade to the developer account type.
Have you thought about adding support for boolean operators in the rule declarations? For example, "empty||valid_email" => "empty or a valid email", or "valid_email&&matches[email]" => "valid email and matches the 'email' field"? Basically, support for !, && (easy since this is the default behavior), and ||. To be honest, the use cases for this functionality is pretty limited but I think it'd be a nice feature to add just for the sake of practice. It would make handling error messages a little more complex though.
I tried to add something like this to a small validation library I wrote about a year ago. I think that part worked pretty well but otherwise it wasn't very well designed. Another problem I ran into was the lack of support for rules that depended on asynchronous operations.
Yeah, that could work actually - I've purposefully left everything to do with symbols (apart from the standard dollar sign) up to the developer, to avoid bloat, but I can see a use case for the most common ones (along with default formatting for said symbols)
His example has an error. He forgot to return newObject at the end of the fromPrototype function. The fromPrototype function returns an instance (an object) that inherits from the given prototype and with the same properties you passed in with the object.
`return` may be a valid statement but an object literal is not.
A standalone object literal would likely be interpreted as a block and would throw a syntax error unless it were a simple identifier and a statement `{ foo: <statement> }`, in which case it would not interpret it as an object but exactly what it is, a label and a statement.
This is why JSON parsers which use eval must first wrap the object literal with parens, to make it an expression rather than a statement.
Never said it was an object literal eh. Object literals can only occur inside expressions, that's pretty well defined in the JavaScript AST too, which is described to the utmost detail in the ECMAScript specs.
The thing is:
- `return` alone is a valid statement in its own.
- The parser just need to use a simple lookahead to decide whether the next line is part of the previous statement.
- The parser DON'T change the meaning of your programs.
All that's beside that is a matter of taste. Whether use semicolons or not is up to what sits better with each person. I'm just arguing against the silly and incorrect "technical" arguments against it.
It seems a little pricey to me. 10,000 page views (for $30) isn't all that much. It's not convenient enough (for me) to justify $99 per month for the next tier of 100K page views.
There will be four variants of the GSII in the US, one for each of the big carriers. "Attain" (AT&T), "Within" (Sprint), "Function" (Verizon), and "Hercules" (T-Mobile). This article (http://www.infosyncworld.com/reviews/cell-phones/samsung-gal...) has a bit more info.
Lately, instead of using the module pattern by invoking a function immediately and returning an object, I've taken to just using an anonymous function/constructor with the new operator -- properties defined under "this" will be public and any other variables will be private (obviously). I prefer it over the typical "module pattern" because I believe it looks just a tad bit cleaner compared to the explicit object definition.
