tag:blogger.com,1999:blog-11683713.post111815104593933166..comments2024-01-12T21:16:50.520-08:00Comments on Spyced: Anders Heljsberg doesn't grok PythonJonathan Ellishttp://www.blogger.com/profile/11003648392946638242noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-11683713.post-1865348567051401632007-03-31T07:58:00.000-07:002007-03-31T07:58:00.000-07:00If your methods are final by default, the compiler...If your methods are final by default, the compiler can even inline the method at the call-site.<BR/><BR/>I'm not sure if an interpreter can do the same kind of optimizations. I guess this is where we all go off and read about StrongTalk, right? I think it performs runtime analysis to determine the most likely implementation at a call-site and tries to inline as much as possible.lbrunohttps://www.blogger.com/profile/13975437897556488014noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-69027052536682188942007-03-02T22:58:00.000-08:002007-03-02T22:58:00.000-08:00but if we were all adults, surely things like secu...but if we were all adults, surely things like security would be less important? but one of the principles of .NET is that code can be verifiably safe. how would you like to provide a class that implemented some security mechanism only to have a derive class decide that it wants to circumvent your security system?<BR/><BR/>"i know we're all adults here, but please, put that gun away."<BR/><BR/>sometimes its better to be safe.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11683713.post-1162355167395325732006-10-31T20:26:00.000-08:002006-10-31T20:26:00.000-08:00This is not about variable scope. You completely ...This is not about variable scope. You completely misunderstood.Jonathan Ellishttps://www.blogger.com/profile/11003648392946638242noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-1162099064894361912006-10-28T22:17:00.000-07:002006-10-28T22:17:00.000-07:00Basically what you are saying is that global varia...Basically what you are saying is that global variables rule, and there is rarely any need for private ones. Never heard anyone admit that before.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11683713.post-1126735360602259942005-09-14T15:02:00.000-07:002005-09-14T15:02:00.000-07:00allowing private members has nothing to do with pr...allowing private members has nothing to do with providing an execution sandbox.<BR/><BR/>fundamentally, rexec was killed because nobody cared enough to maintain it when problems were found. that's how open source works.Jonathan Ellishttps://www.blogger.com/profile/11003648392946638242noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-1119047298908503962005-06-17T15:28:00.000-07:002005-06-17T15:28:00.000-07:00As much as the opaqueness and inflexibility of C# ...As much as the opaqueness and inflexibility of C# and Java code can be vexing, it does allow them (or at least others building upon the basic structures of the language) to achieve a degree of security which Python can never hope to achieve. There is a reason the rexec and bastion bits went away...people realized that the inability to prevent access to some variables made the attempts to create a restricted execution environment a fool's errand.<BR/><BR/>I _love_ the flexiblity that the Python interpreter allows, but there are instances where it would be nice to be able to create some sort of restricted execution environment...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11683713.post-1118157708390064432005-06-07T08:21:00.000-07:002005-06-07T08:21:00.000-07:00I like this post very much, and it gets me to thin...I like this post very much, and it gets me to thinking about these issues, which, for the most part, are swallowed whole by people that are taught these ideas because we assume someone knows better than we do (i.e. I learned many things in school that I only recently started questioning, and the importance of 'private' variables is one of them. I am not saying I don't still think they are important, but I will have to give it some thought.<BR/><BR/>The quote, "denying derived classes full access to your inner workings just leads to clumsier (less readable and more bug-prone) implementations derivations" rings true for me, as well as your mention of the fact that .NET framework classes are sealed, etc. I wanted to extend the StringBuilder class a bit, but was not able to. Instead, I wrapped it (aggregated it) in a class and although it works, it is not as 'pretty' as I would like it (i.e. not as OO as I would like it). Well, too bad Anders doesn't devote more time to looking at these matters. I think someone needs to drop him a line. Why don't you write him and more fully express these very points for him? I think it would be a good thing.Anonymousnoreply@blogger.com