tag:blogger.com,1999:blog-20975090.post6461478595994478271..comments2024-03-11T10:18:55.852-05:00Comments on Headius: To Keyword Or Not To KeywordCharles Oliver Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-20975090.post-78703189728745493982007-07-17T01:11:00.000-05:002007-07-17T01:11:00.000-05:00El Raichu: Except that users can't use send to inv...El Raichu: Except that users can't use send to invoke a number of other features like "alias". In that case, Ruby has both a keyword and a method with expected behaviors. There's already a split in the consistency of behaviors here.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-85840706084418321902007-07-16T22:13:00.000-05:002007-07-16T22:13:00.000-05:00these offenders may be able to do things that no m...these offenders may be able to do things that no method can do, but ruby programmers can play around with them in the same way they do with other methods. they can use Object#send, Method#call, etc. because they expect them to be methods, not keywords, and they are least likely to be surprised when they use them in that way. i don't think the speed boost is worth the split in the consistency of the programmers' expectations.El Raichuhttps://www.blogger.com/profile/04126486217060569000noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-68167820135154477502007-07-16T16:41:00.000-05:002007-07-16T16:41:00.000-05:00Could it be an alternative to let the actual keywo...Could it be an alternative to let the actual keyword-handing behaviour be specified as a command-line switch to the interpreter? (ie "optimized" or "true ruby")Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-91026079314909049392007-07-16T05:04:00.000-05:002007-07-16T05:04:00.000-05:00Okay, I'll stand corrected on that one. Kind of o...Okay, I'll stand corrected on that one. Kind of obvious, I suppose; what's really needed is for the scope you want these things to run in to be a parameter to the method. But that would imply giving these methods special treatment, which would still be kind of broken.<BR/><BR/>I'd still vote for fixing the issues related to this, rather than keyword-izing them.<BR/><BR/>But that's just because I don't like languages with heaps of keywords.<BR/><BR/>I think the other issue that someone pointed out (language standardization across implementations) is probably more important -- if these are going to become keywords, they should become so everywhere.Unknownhttps://www.blogger.com/profile/17249200538291402347noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-18227771657712977792007-07-13T23:44:00.000-05:002007-07-13T23:44:00.000-05:00Rather ironic you bring this up while in PythonLan...Rather ironic you bring this up while in PythonLand we are removing keywords from the language for Python 3.0. It's especially ironic since the 'exec' keyword is becoming a function. =)<BR/><BR/>The reason for our desire to ditch the keyword is that it's not used often enough to warrant keyword support and thus complicate the language. Yes, it requires interpreter support (probably one of the reasons it was a keyword to begin with), but neither Jython nor IronPython have complained about implementation performance to warrant a change.<BR/><BR/>But I do understand wanting to speed them up. Plus I don't program in Ruby often enough to know how frequently the new keywords you are proposing are used.Anonymoushttps://www.blogger.com/profile/15754007124078149155noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-81610086976999621152007-07-13T13:46:00.000-05:002007-07-13T13:46:00.000-05:00fHmm... I just realised that I'm mistaken about th...fHmm... I just realised that I'm mistaken about the way local_bindings behaves when you eval it with a binding. I just wasn't thinking carefully enough about what goes on.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-9926791235690123532007-07-13T13:36:00.001-05:002007-07-13T13:36:00.001-05:00Simon: Actually, no you can't. If you override, sa...Simon: Actually, no you can't. If you override, say 'local_variables', then when you call the 'real' local_variables, you'll get a list of the local variables in your overriding method. What you'd need to do is (somehow) capture the binding of your caller and then do something like<BR/><BR/> eval "local_variables", binding_of_caller<BR/><BR/>Except that doesn't actually work, the method ignores the binding it's being evalled with and instead returns the local variables associated with the context that calls the eval.<BR/><BR/>Which is enormously annoying when you think about it. One more thing that makes implementing the Extract Method refactoring in Ruby that bit trickier. Ho hum.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-3585129092145310672007-07-13T13:36:00.000-05:002007-07-13T13:36:00.000-05:00Nic and Simon: I think you are mistaken. Although ...Nic and Simon: I think you are mistaken. Although you can alias these methods, you can't ever wrap or hook their behavior. An example with eval:<BR/><BR/>alias :my_eval :eval<BR/><BR/>def eval(string)<BR/> my_eval(string)<BR/>end<BR/><BR/>x = 1<BR/>eval("puts x") #=> error<BR/><BR/>The actual eval call must be made within the scope where you expect it to run, so there's no way to wrap it. The same goes for the others; binding would get the wrong binding, public/private/protected would set visibility in the wrong scope, and so on. That means these methods are basically impossible to wrap or hook, which is the primary argument for keeping them methods.<BR/><BR/>Bottom line is that these aren't methods...they're keyword operations that do things no method can do. They should be keywords.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-41103897899078209562007-07-13T07:42:00.000-05:002007-07-13T07:42:00.000-05:00I'm also not sure whether changing the language to...I'm also not sure whether changing the language to make optimization easier is necessarily the best way to go.<BR/><BR/>It sort of isn't necessarily important that these methods can't be implemented in-language (it may be nice if they could be) -- as Dr Nic pointed out, you can augment their behaviour and call the old versions to get access to their implementations.<BR/><BR/>I guess if there's a way to detect if they're overridden (as you're doing), then that's the best way to do it.Unknownhttps://www.blogger.com/profile/17249200538291402347noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-4922375243008790262007-07-13T05:34:00.000-05:002007-07-13T05:34:00.000-05:00The figures definitely seem to show that the optim...The figures definitely seem to show that the optimization is worthwhile, although whether making those particular methods keywords is the best solution, I don't know.<BR/><BR/>Aside from that particular issue (To Keyword Or Not To Keyword), I think there are two interesting questions being raised:<BR/>* should Ruby the language be changed to work around an implementation detail (even if this is common to all implementations)?<BR/>* How open is Ruby governance? And how open should it be?<BR/><BR/>This, along with the ObjectSpaces issue you raised (also for performance reasons from what I remember), will prove interesting tests of both - I, for one, wouldn't know what the right answer is.Nickhttps://www.blogger.com/profile/15024763194605299792noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-10009418628269431132007-07-13T05:01:00.000-05:002007-07-13T05:01:00.000-05:00As they are methods you can still alias them/overr...As they are methods you can still alias them/override them and then recall them as necessary, so all is not lost. Making them keywords removes these options.Dr Nichttps://www.blogger.com/profile/17833227514368162020noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-72148375579951508872007-07-13T02:13:00.000-05:002007-07-13T02:13:00.000-05:00Speculative optimization is what I'm planning to d...Speculative optimization is what I'm planning to do now, assuming they're keyword-like and only falling back on the old behavior (probably globally) if I can detect that's not the case. the problem is whether I can detect it or not.<BR/><BR/>Another option is to lazily initialize the runtime constructs in question only at the point I know they're needed, but that's extremely complicated to implement in practice.<BR/><BR/>It's worth mentioning that Rubinius, while far from being a complete Ruby implementation, has already opted to treat these operations as keywords. Evan's on board with the idea too.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-57511756771127749092007-07-13T02:07:00.000-05:002007-07-13T02:07:00.000-05:00Personally, I'd like to see Ruby get the ability t...Personally, I'd like to see Ruby get the ability to implement most of those constructs in Ruby, but I doubt that's going to happen at any time in 1.8. <BR/><BR/>Can you do the optimization 'speculatively' and watch for any attempt to redefine any of the methods that would invalidate the optimization?Anonymousnoreply@blogger.com