Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

language design questions #21

Open
dvv opened this issue Apr 2, 2012 · 5 comments
Open

language design questions #21

dvv opened this issue Apr 2, 2012 · 5 comments

Comments

@dvv
Copy link
Contributor

dvv commented Apr 2, 2012

Please, consider answering some naive ones:

  1. why coercing comparison retains: ==, !=. they are known as source of subtle bugs in JS, and every tutorial i read said i should use ===, !== instead.
  2. delete foo[bar] can be replaced with foo[bar] = nil, which frees rather useful keyword and can internally behave equally.
  3. string concatenation is done via ambiguous +, which is known to be another source of subtle bugs.

TIA,
--Vladimir

@creationix
Copy link
Contributor

delete is not the same as setting to nil. This is not lua. Candor allows having properties that point to nil. This makes JSON interop much easier for example.

As far as type coercion, I agree, == and != should be the same as JS === and !==.

@dvv
Copy link
Contributor Author

dvv commented Apr 2, 2012

will candor distinguish between delete foo[bar] and delete(foo[bar]) and {delete: (foo) { bar } }?

@creationix
Copy link
Contributor

I believe so yes. If not, it should. I know I asked for this with "new" and I assume the logic is the same for all keywords.

@dvv
Copy link
Contributor Author

dvv commented Apr 2, 2012

hmm. i saw no new in keywords. i thought we construct objects literally, no?

@creationix
Copy link
Contributor

right, "new" was renamed to "clone". But it was "new" when I had @indutny make sure it could be used for other stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants