Hey matz, thanks for taking the time to respond to these. > I'd like to see them as separated RCRs, even though the new RCR site > have not seen its successful start-up yet. If the RCR process gets fixed I would be happy to do some of them. Right now only two people have submitted RCRs (last I checked) and the communication on those RCRs is either broken or simply not being used --I made attempts at emailing on the second --and I sumbitted the first ;-) > The biggest reason we don't have caller binding API is the difficulty > of the implementation under the current interpreter. ko1 once said it > is possible for YARV, so all we need is to design good API. I don't > think of_caller is the best name for it. Really? By simply passing a block I can pass the binding of the caller. I suppose passing a hidden block is too heavy though? > By the way, YARV was committed in the Subversion trunk yesterday. w00t! > Could you describe what this change give you? Removing class method > does not allow local variables to be named 'class'. Besides that I > don't like the name "object_class", which is too vague for me. class > of an object? a class object? an object which is a class? whatever. > Maybe because I see many combination of "something id" but not > "something class", besides "business class" etc. The main thing is that it creates an exception b/c we are forced to use a reciever, eg. self.class, so it can't be called as a "function" nor made private. No other method is like that. Also I don't see why we can't use it as a local var. Isn't the conflict with class<<obj notation? Probably the parser should see /class\s+<</ as a whole unit, which I think would allow for the var. But if you ask me the whole "class << obj" notaton is yuk anyway. It visually clashes with Array#<< and I'd much prefer someting like 'obj.meta_eval' -or- 'obj.singleton_eval'. > |* Allow a comma between the two <code>alias</code> arguments --getting > |an error on that is really annoying. Actually why is <code>alias</code> > |a keyword? Why have both <code>#alias_method</code> and > |<code>alias</code>? I have always been told that keywords were to be > |avoided. > > Are you proposing comma between alias arguments, or removal of the > alias keyword? Well, both. First and foremost however is the option of a comma. What good reson is there for getting getting a sytax error here? As for makeing alias a real method, that seems like a good idea. it would allow us to use 'alias' as a var too. If it possible to get rid of an exception and have things still work fine, then it's a good thing, isn't it? > |* <code>String#resc</code> as an inversion of > |<code>Regexp.escape(string)</code> and <code>String#to_re</code> as an > |inversion of <code>Regexp.new(string)</code>. > > Why? It's much more concise. Take a simple example: re = /^#{user_input}/ We need to escape it: re = /^#{Regexp.escape(user_input)}/ vs. re = /^#{user_input.resc}/ The to_re, just goes hand in hand with resc, since they both regular expresions --maybe resc should be to_resc, but tersness is especially useful with it so I suggest resc instead. > |* I'm dying here from remove_method hacks without > |<code>#instance_exec</code>. This has to rank in the top three "little > |things" that have been talked about forever, and it isn't that hard to > |implement. So what's holding it up? > > We have it in 1.9. Yea! But why not a 1.8 serious. It's an additon it won't break anything. Correct me if I'm wrong, but I fear we won't see anything from 1.9 in production for almost 2 years. > |* Close the closures. Writing DSLs is great, but have you noticed they > |all share the same closure? Have a way to reset the closure with some > |sort of special block notation would shore-up this danger hole. Maybe: > | > |<pre> > | a = 1 > | dosomething do! |x| > | p a #=> error > | end > |</pre> > > I am not sure what you meant here. Could you elaborate (maybe in a > separate post)? Does any other language address this issue? Okay. I will post separately. > We have send, funcall, __send, __send! in 1.9. Do we need more? So we have the functionality. But can you tell me with a straight face those are great method names? Peronally, I really think you should get rid of __shadow methods wherever you can. All it indicates is that the original method's name is too common, so is likely to be overridden. And that's the reason I suggest #object_send. All methods starting with object_ or instance_ are special. They are meta-programming methods and as such need to stand aside in some fashion to avoid being overridden easily. This consistancy is the beauty of it. > In short, you are asking for the alias for Module#===, right? > I don't see any good reason for it, where we can call > > myobject.instance_of?(MyClass) > > but the good name for it would help accepting the proposal. Yes. that's right. But I learned that it is better to ask the class if you want to know the "truth". Sometimes the object might need to lie --eg. as a proxy. I guess the most obvious name is: MyClass.class_of?(myobject) > |* Oh, and lets not forget the forever arguable method name for (class > |<< self; self; end). But please give us something concise. > > Yes, the name is the biggest obstacle now. #supercalifragilisticexpialidocius Almost anything is better than nothing at this point.... okay maybe not THAT, but you get my point. > |No doubt there other little things left unmentioned, and obviously some > |are more important than others. But in any case, it's clearly striking > |that after hearing for so long about many such well-accepted "little > |things", that Ruby has yet to take them in. I have a silly theory about > |this actually --as odd as it may seem. The 1.9 version is the last on > |the chain before 2.0 b/c matz is against using double-digit minor > |numbers, eg 1.10. So we're is stuck with 1.9 as his test bed for 2.0. > |Since 1.8 can only increment by teeny, these "little things", being not > |little enough, can't make it in. Hence Ruby is being held back by a > |version number policy!!! I think Matz just needs to get on with it (hey > |look forward to 3.0!) or just lossen the version policy constraints. > > Digits that we have many (hey, we could have 9 more major releases!) Good! :-) > are not the reason. Expected screams from all over the world suspends > incompatibility and behavior changing for 1.8. Yet most of these have no backward compatability issues --I guess that's really my main point with "Little things" Thanks and happy new year, T.