tag:blogger.com,1999:blog-5783184094166463434.post4842995466937195180..comments2022-03-16T09:24:58.770+01:00Comments on Jangaroo: Simulating ActionScript in JavaScript: Private MembersDennishttp://www.blogger.com/profile/09456446381126510943noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5783184094166463434.post-45393204149577767692012-12-08T02:13:04.641+01:002012-12-08T02:13:04.641+01:00Another new idea for a little improvement:
Instead...Another new idea for a little improvement:<br />Instead of using the pattern privateField$1, which is a valid ActionScript identifier and thus could name-clash with a field specified explicitly by the developer, we could better use a separator character that is not allowed in an ActionScript identifier, like ' ' (space). The generated code would have to use square brackets notation, like so: this['privateField 1'].<br />Obviously, the disadvantage is that it looks and types less nicely in the debugger.Frankhttps://www.blogger.com/profile/07941551987898697351noreply@blogger.comtag:blogger.com,1999:blog-5783184094166463434.post-9307063437407078972012-12-08T02:05:28.639+01:002012-12-08T02:05:28.639+01:00One important argument against using JavaScript in...One important argument against using JavaScript information hiding a la Crockford and also my "private this" solution I realized only now is that it does not resemble the ActionScript semantics!<br />While JavaScript privates are private to an object, ActionScript privates are, like in Java, private to a class. That means in ActionScript, an instance of class A may access a private member defined in A not only on "this", but also on any other instance of A. This is often used in equals() method implementations.<br />I think being more strict than the original ActionScript semantics is a no-go. Your code is "green" and compiles, but then at runtime, you are told "other.foo is undefined"?!Frankhttps://www.blogger.com/profile/07941551987898697351noreply@blogger.comtag:blogger.com,1999:blog-5783184094166463434.post-80942745172843469052011-12-06T09:30:10.035+01:002011-12-06T09:30:10.035+01:00The follow-up post about untyped private member ac...The <a href="http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html" rel="nofollow">follow-up post about untyped private member access</a> is online now!Frankhttps://www.blogger.com/profile/07941551987898697351noreply@blogger.comtag:blogger.com,1999:blog-5783184094166463434.post-40955734178616252432011-12-04T23:42:03.073+01:002011-12-04T23:42:03.073+01:00Bernd,
I hope I didn't miss the point of your ...Bernd,<br />I hope I didn't miss the point of your question, but Jangaroo does <i>not</i> try to catch private member access violations at runtime. As said in the blog post, the reason to rename private members is to avoid name clashes, and all renaming is done at compile time.<br />However, you spotted an issue I skipped in the blog post: What about untyped access to private members? How can the Jangaroo compiler rename access to a private member, if the expression to the left of the dot is untyped?<br />Since the answer is rather long, I am already working on a follow-up blog post.<br />The idea you mention to generate different code for debug and release builds is already implemented in Jangaroo. We provide a built-in assert() function that is interpreted by the compiler: If assertions are disabled (using a compiler flag you could set when creating release builds), assert() function calls are completely suppressed in the generated code. So if there were any runtime checks for private member access (which, as said above, is not the case), they could be treated similarily.Frankhttps://www.blogger.com/profile/07941551987898697351noreply@blogger.comtag:blogger.com,1999:blog-5783184094166463434.post-72661687981754229492011-12-04T02:58:40.098+01:002011-12-04T02:58:40.098+01:00This is all very interesting. Thanks for sharing t...This is all very interesting. Thanks for sharing those details! The way Jangaroo hides private members is crafty. But I am wondering: Shouldn't most access violations due to accessing private members be caught at compile time? In theory the only reason for checking access violations at runtime is because of untyped code, i.e. assuming that foo() is a private method of Sprite:<br /><br />var sprite: Sprite = new Sprite();<br />var spriteObj : Object = sprite;<br />spriteObj.foo();<br /><br />I am simply wondering: Shall Jangaroo care about those cases? I think so. But in my opinion Jangaroo should only care about access violations debug builds. In release builds I would not use any code that checks against access violations.<br />That is what I call the "dart rules". Please see this blog post if you are interested in the details and let me know what you think:<br />http://blogs.adobe.com/bparadie/2011/11/16/dart-and-types-tennis-without-a-net/Bernd Paradieshttp://blogs.adobe.com/bparadie/noreply@blogger.com