tag:blogger.com,1999:blog-4704664917418794835.post8276177780686692218..comments2023-07-01T05:41:30.469-07:00Comments on Headius: To Keyword Or Not To Keywordheadiushttp://www.blogger.com/profile/15717357218364947795noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-4704664917418794835.post-54466992522734097192007-07-13T00:07:00.000-07:002007-07-13T00:07:00.000-07:00Personally, I'd like to see Ruby get the abili...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?Piers Cawleyhttp://www.bofh.org.uk/noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-46720002545340875582007-07-13T00:13:00.000-07:002007-07-13T00:13:00.000-07:00Speculative optimization is what I'm planning ...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 Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-77465900369537578982007-07-13T03:01:00.000-07:002007-07-13T03:01:00.000-07: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 Nichttp://www.blogger.com/profile/17833227514368162020noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-66848958811534276282007-07-13T05:42:00.000-07:002007-07-13T05:42:00.000-07:00I'm also not sure whether changing the languag...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.Simonhttp://www.blogger.com/profile/17249200538291402347noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-21704780988004949892007-07-13T11:36:00.002-07:002007-07-13T11:36:00.002-07: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 Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-12741368116049620792007-07-13T11:46:00.000-07:002007-07-13T11:46:00.000-07:00fHmm... I just realised that I'm mistaken abou...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.Piers Cawleyhttp://www.bofh.org.uk/noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-35276325324099865192007-07-16T14:41:00.000-07:002007-07-16T14:41:00.000-07: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-4704664917418794835.post-6333082063334501322007-07-16T20:13:00.000-07:002007-07-16T20:13:00.000-07: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 Raichuhttp://www.blogger.com/profile/04126486217060569000noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-54134809630318639612007-07-16T23:11:00.000-07:002007-07-16T23:11:00.000-07:00El Raichu: Except that users can't use send to...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 Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.com