Comments on Ruby

[Bill Atkins]

I've been using Ruby for about a month now and it's become my favorite
language by far. I don't know if RCR's are still being accepted, but
I know you're supposed to post changes here before submitting. So
here are some things I've noticed. I don't know if any are worthy of
change requests, but here they are.

1. def ought to return a Method object. Just because. Having def
return an object adds a little bit of consistency, IMO.

2. Top-level defs should be singleton methods in an Object instance
dedicated to that file. It's messy that a top-level def can be called
on any object.

3. The pipes on a parameter list for a do block ought to be optional.
I'm not sure about this one.

4. caller should provide the sender of the current message.

5. All special $ variables out to be deprecated or even removed.

6. There ought to be some way to assign to a receiver object, or
overload = or something.

7. Perhaps some kind of site-level initialization file in
lib/site_ruby that would be called before any script is loaded to add
methods to the default classes.

Some of these are probably crazy. Please don't take offense to them.

That's all I have for now.

 

[gabriele renzi]

il 14 Apr 2004 11:24:03 -0700, (e-mail address removed) (Bill Atkins) ha
scritto::

I've been using Ruby for about a month now and it's become my favorite
language by far. I don't know if RCR's are still being accepted, but
I know you're supposed to post changes here before submitting. So
here are some things I've noticed. I don't know if any are worthy of
change requests, but here they are.

feel free to post rcr to
http://www.rcrchive.net
the discussion about them happens there as well and is saved for
posterity

1. def ought to return a Method object. Just because. Having def
return an object adds a little bit of consistency, IMO.

I'd prefer a symbol, FWIW

2. Top-level defs should be singleton methods in an Object instance
dedicated to that file. It's messy that a top-level def can be called
on any object.

Not sure I understand, if you want methods not in top òlevel why don't
you use a module?

3. The pipes on a parameter list for a do block ought to be optional.
I'm not sure about this one.

it makes block impossible to parse, I believe. I suggested removing
just one of the pipes and that mad blocks hard to parse anyway

5. All special $ variables out to be deprecated or even removed.

they will, just not too soon, google for one of the last ruby-dev
summaries

 

[gabriele renzi]

I'd prefer a symbol, FWIW

But a symbol itself has no connection back to the class or method. Should it
instead be some object that combined [UnboundMethod + Symbol], or something
like that?

this has been suggested already IIRC.
My point is that
- I never used an UnboundMethod
- I could write 'private def f(); end

Nothing really important.

After that Obviously I'll ask for public/private/protected to return
anopther symbol, and concatenate final() abstract() synchronized() and
stuff like that

 

[Dick Davies]

il Wed, 14 Apr 2004 18:38:31 GMT, "Its Me" <[email protected]> ha
scritto::

1. def ought to return a Method object. Just because. Having def
return an object adds a little bit of consistency, IMO.
I'd prefer a symbol, FWIW

But a symbol itself has no connection back to the class or method. Should it
instead be some object that combined [UnboundMethod + Symbol], or something
like that?

this has been suggested already IIRC.
My point is that
- I never used an UnboundMethod
- I could write 'private def f(); end

I remember from my nuby days (ok, ok, my *total* nuby days) a thread on this -
the separate 'private :meth" line was the only thing that grated on me when I first
started. Did that ever go anywhere?

After that Obviously I'll ask for public/private/protected to return
anopther symbol, and concatenate final() abstract() synchronized() and
stuff like that

Oh, *they* can stay back in PoorMansSmalltalk land please. They're part of
the reason I left

 

[nobu.nokada]

Hi,

At Thu, 15 Apr 2004 03:24:16 +0900,
Bill Atkins wrote in [ruby-talk:97173]:

1. def ought to return a Method object. Just because. Having def
return an object adds a little bit of consistency, IMO.

Method object is not method itself, rather a wrapper for it,
whereas Class is the class itself. I feel Symbol would be
enough.

2. Top-level defs should be singleton methods in an Object instance
dedicated to that file. It's messy that a top-level def can be called
on any object.

If you feel so, don't use top-level methods, define in
meta class.

class << self
def foo
end
end

Methods need to be visible everywhere would be top-level.

3. The pipes on a parameter list for a do block ought to be optional.
I'm not sure about this one.

By "pipes", do you mean this?

foo do |this| end

Then, it's optional, you can omit it if you don't use it.

4. caller should provide the sender of the current message.

Particular method instead of parsing strings?

5. All special $ variables out to be deprecated or even removed.

It will.

6. There ought to be some way to assign to a receiver object, or
overload = or something.

Assignment is not an operation on an object.

7. Perhaps some kind of site-level initialization file in
lib/site_ruby that would be called before any script is loaded to add
methods to the default classes.

Use RUBYOPT environment variable.

 

[Stephan Kämper]

Hi,

By "pipes", do you mean this?

foo do |this| end

Then, it's optional, you can omit it if you don't use it.

I understood that he liked the pipe characters to be optional, but not
neccessarily the parameter list, so as to be allowed to wrint something
like this:

some_method do a_param, one_more, and_another

# use them here

end

"which is, of course impossible" (Douglas Adams)...

Happy rubying

Stephan

 

[Stephan Kämper]

Hi,

By "pipes", do you mean this?

foo do |this| end

Then, it's optional, you can omit it if you don't use it.

I understood that he liked the pipe characters to be optional, but not
neccessarily the parameter list, so as to be allowed to write something
like this:

some_method do a_param, one_more, and_another

# use them here

end

"which is, of course impossible" (Douglas Adams)...

Happy rubying

Stephan