Trans
12/31/2006 11:41:00 PM
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.