Hi,
I’d like to see them as separated RCRs, even though the new RCR site
have not seen its successful start-up yet.
In message “Re: Little Things”
on Sun, 31 Dec 2006 02:27:14 +0900, “Trans” [email protected]
writes:
|* Binding.of_caller. Yes, it’s easy to abuse, and should be avoided at
|nearly all costs. But there are few pennies worth when nothing else
|will do. Some very cool metatricks are made possible by being able to
|access the caller’s binding --the breakpoint lib being the most well
|known.
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.
By the way, YARV was committed in the Subversion trunk yesterday.
|* object_class instead of class. I get sick
|just looking at self.class.foo. And it prevents use of
|“class” for other variables/methods. (Hence the all too frequent use of
|“klass”). object_class on the other hand is nicely
|analogous to object_id.
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.
|* Allow a comma between the two alias arguments --getting
|an error on that is really annoying. Actually why is alias
|a keyword? Why have both #alias_method and
|alias? I have always been told that keywords were to be
|avoided.
Are you proposing comma between alias arguments, or removal of the
alias keyword?
|* String#resc as an inversion of
|Regexp.escape(string) and String#to_re as an
|inversion of Regexp.new(string).
Why?
|* I’m dying here from remove_method hacks without
|#instance_exec. 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.
|* A block can’t take a block, nor default arguments. What kind of
|define_method is this? I realize this a trickier issue.
|But at some point the trick has to be performed.
We have it in 1.9; well, at least partially.
|* 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:
|
|
| a = 1
| dosomething do! |x|
| p a #=> error
| end
|
I am not sure what you meant here. Could you elaborate (maybe in a
separate post)? Does any other language address this issue?
|* Another hassle when metaprogramming. #send should work
|for public methods only! There’s a big issue with backward
|compatibility here. I have the solution: #object_send.
|It’s a better name anyway b/c it stays out of the way (eg. my Email
|module would like to have a #send method, you dig?). And #send itself
|could be deprecated slowly. BTW #funcall for the alternate
|private-accessing send is a terrible name, try
|#instance_send. (And yes, I’m begging here!)
We have send, funcall, __send, __send! in 1.9. Do we need more?
|* This one’s more of my own pet-peeve but nontheless, who wouldn’t want
|a nice word alias for Class#===. In most cases I prefer to read what
|I’m doing rather then recall the interpretation of a symbol. There are
|of course some symbols that are rather obvious, either by indication of
|their form (eg. <<) or by their widespread use (eg. =), but Class#===
|is not one of them. I would much prefer to see:
|
|
| MyClass.instance?(myobject)
|
|
|But I’m not picky about what word to use as long as it’s readable.
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.
|* 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.
|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!)
are not the reason. Expected screams from all over the world suspends
incompatibility and behavior changing for 1.8.
matz.
