Yet another example of the horrible mess unprincipled automatic type conversion causes.<p>What prevents language designers from avoiding all these lurking bugs with a generic type-conversion operator? E.g. here's how it might look in a Python-like language:<p><pre><code> >>> x = 1
>>> y = "2"
>>> print(x + cast(y))
3
>>> print(cast(x) + y)
"12"
>>> print(cast(x) + cast(y))
Exception: ambiguous type</code></pre>
I'm curious on what the performance implications are. If I have some JavaScript on a webpage that I want to "obfuscate", would using this accomplish the task?
I've seen this before here: <a href="http://www.jsfuck.com/" rel="nofollow">http://www.jsfuck.com/</a>.<p>It's nice that this guy actually explains how it works
> For instance, here is 4: !+[]+!![]+!![]+!![].<p>Gotta love this language... It's a wonder we can get any work done with it. But, used with discipline, it's not too bad.
I am not a programmer so this is part curiosity and part criticism. Why do programmers seem to enjoy creating programs that satisfy some syntactical constraint? Is it a fun mental exercise, or or can you just admit that you're showing off on something that really does not matter?
I once did something similar in PHP.[1] View the semi-useful writeup[2] as well.<p>[1]: <a href="https://gist.githubusercontent.com/nubs/5849633/raw/78bae58f6675f4e514d7a784c3142dd7d98f0629/nodigitsorquoteseither.php" rel="nofollow">https://gist.githubusercontent.com/nubs/5849633/raw/78bae58f...</a><p>[2]: <a href="https://gist.github.com/nubs/5849633" rel="nofollow">https://gist.github.com/nubs/5849633</a>
This method could also be used to evade XSS filters.<p>For e.g. I believe encoding code using something similar is the only way to solve this challenge - <a href="http://escape.alf.nu/9/" rel="nofollow">http://escape.alf.nu/9/</a>
Encoder for a similar subset: <a href="http://utf-8.jp/public/jjencode.html" rel="nofollow">http://utf-8.jp/public/jjencode.html</a>