I've been using Ruby for years, and it just occurred to me to ask:
where did the convention of referring to methods using a
hash/pound/octothorpe symbol (#), as in "#foo" or "MyClass#bar", come
from? Is it a Smalltalk thing, or what?
Avdi
I've been using Ruby for years, and it just occurred to me to ask:
where did the convention of referring to methods using a
hash/pound/octothorpe symbol (#), as in "#foo" or "MyClass#bar", come
from? Is it a Smalltalk thing, or what?
Avdi
Avdi Grimm wrote:
where did the convention of referring to methods using a
hash/pound/octothorpe symbol (#), as in "#foo" or "MyClass#bar", come
from?
Isn't this a PickAxe convention to differentiate the class methods
(MyClass.class_method) from the instance methods
(MyClass#instance_method)?
It predated the PickAxe--it was in a lot of Ruby documentation before that.
FWIW, I now regret carrying that forward into the book. I think I'd probably do
string (in String)
rather than String#strip if I were doing it again.
On Jan 22, 2007, at 10:10 AM, Curtis Summers wrote:
Isn't this a PickAxe convention to differentiate the class methods
(MyClass.class_method) from the instance methods
(MyClass#instance_method)?
i like
File::class_method
File.instance_method
the reason is that both work in the shell without funky quoting unlike
ri 'File#instance_method' # egads that's a comment!
and is consitent with actual calling conventions.
using parens wouldn't do ri users any favours i think...
2 cts.
-a
On Tue, 23 Jan 2007, Dave Thomas wrote:
On Jan 22, 2007, at 10:10 AM, Curtis Summers wrote:
Isn't this a PickAxe convention to differentiate the class methods
(MyClass.class_method) from the instance methods
(MyClass#instance_method)?It predated the PickAxe--it was in a lot of Ruby documentation before that.
FWIW, I now regret carrying that forward into the book. I think I'd probably do
string (in String)
rather than String#strip if I were doing it again.
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama
I must confess I really like the haystack syntax, especially because
it's not valid calling syntax in Ruby, but also because it's very
concise.
Cheers,
Daniel
On Tue, 2007-01-23 at 02:01 +0900, Dave Thomas wrote:
On Jan 22, 2007, at 10:10 AM, Curtis Summers wrote:
> Isn't this a PickAxe convention to differentiate the class methods
> (MyClass.class_method) from the instance methods
> (MyClass#instance_method)?It predated the PickAxe--it was in a lot of Ruby documentation before
that.FWIW, I now regret carrying that forward into the book. I think I'd
probably dostring (in String)
rather than String#strip if I were doing it again.
i like
File::class_method
File.instance_method
[...]
and is consitent with actual calling conventions.
Huh? Maybe you mean: file.instance_method (lower case f).
file.gets # ok, assuming file is an instance of File
File.gets # no such method
Gary Wright
On Jan 22, 2007, at 12:04 PM, ara.t.howard@noaa.gov wrote:
The problem with that is that both are valid calling sequences for class methods. If I'd used the following in the book
String.split
I'll get lots of email saying "when I type String.split it doesn't work"
I toyed for a while with the Smalltalk-like a_string.split, but that's ugly and confusing. It's what I use in the library reference, because I set up the context for a_string in the description of the constructor. However, I just don't think it would work in narrative body text.
On Jan 22, 2007, at 11:04 AM, ara.t.howard@noaa.gov wrote:
i like
File::class_method
File.instance_method
>
>
>> Isn't this a PickAxe convention to differentiate the class methods
>> (MyClass.class_method) from the instance methods
>> (MyClass#instance_method)?
>
>
> It predated the PickAxe--it was in a lot of Ruby documentation before that.
>
> FWIW, I now regret carrying that forward into the book. I think I'd probably
> do
>
> string (in String)
>
> rather than String#strip if I were doing it again.
Ick.
i like
File::class_method
File.instance_method
the reason is that both work in the shell without funky quoting unlike
ri 'File#instance_method' # egads that's a comment!
and is consitent with actual calling conventions.
using parens wouldn't do ri users any favours i think...
2 cts.
The obvious solution is to modify irb so that it understands that
notation.
Knowing Mauricio, he's probably already done it.
Regards,
Dan
ara.t.howard@noaa.gov wrote:
On Tue, 23 Jan 2007, Dave Thomas wrote:
> On Jan 22, 2007, at 10:10 AM, Curtis Summers wrote:
hmm. how about this for convention
String.new.split # instance method
String.split # class method
it's true that 'AClass.new.a_method' may or may not be excutable code - but
neither is AClass#a_method.
in any case i think a convention that plays well in the shell with ri would be
a nice addition to the uber convention setter that is the pickaxe
cheers.
-a
On Tue, 23 Jan 2007, Dave Thomas wrote:
On Jan 22, 2007, at 11:04 AM, ara.t.howard@noaa.gov wrote:
i like
File::class_method
File.instance_method
The problem with that is that both are valid calling sequences for class methods. If I'd used the following in the book
String.split
I'll get lots of email saying "when I type String.split it doesn't work"
I toyed for a while with the Smalltalk-like a_string.split, but that's ugly and confusing. It's what I use in the library reference, because I set up the context for a_string in the description of the constructor. However, I just don't think it would work in narrative body text.
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama
modifying ri can't address the issue. the issue is that if one types this at
the shell prompt
~ > ri String#split
#^^^^^
this is a comment in the __shell__
so ri never see anything after the '#'. that's why we have to type
ri 'String#split'
which is truly icky!
-a
On Tue, 23 Jan 2007, Daniel Berger wrote:
The obvious solution is to modify irb so that it understands that
notation.Knowing Mauricio, he's probably already done it.
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama
What shell are you using? Bash and ksh seem to accept 'ri String#split'
just fine. I don't think they consider # the start of a comment unless
it is preceded by white space.
Gary Wright
On Jan 22, 2007, at 2:56 PM, ara.t.howard@noaa.gov wrote:
modifying ri can't address the issue. the issue is that if one types this at
the shell prompt~ > ri String#split
#^^^^^
this is a comment in the __shell__so ri never see anything after the '#'. that's why we have to type
ri 'String#split'
First, something is wrong with your ri or your shell, because it works
fine for me.
Second, stop using ri and start using fri (fast-ri).
Regards,
Dan
ara.t.howard@noaa.gov wrote:
On Tue, 23 Jan 2007, Daniel Berger wrote:
>
> The obvious solution is to modify irb so that it understands that
> notation.
>
> Knowing Mauricio, he's probably already done it.modifying ri can't address the issue. the issue is that if one types this at
the shell prompt~ > ri String#split
#^^^^^
#^^^^^
this is a comment in the __shell__so ri never see anything after the '#'. that's why we have to type
ri 'String#split'
which is truly icky!
>
>The obvious solution is to modify irb so that it understands that
>notation.
>
>Knowing Mauricio, he's probably already done it.modifying ri can't address the issue. the issue is that if one types this
at
the shell prompt~ > ri String#split
#^^^^^
#^^^^^
this is a comment in the __shell__so ri never see anything after the '#'. that's why we have to type
ri 'String#split'
Get a better shell? <g>
ri String#split works just fine for me in zsh
On Tue, Jan 23, 2007 at 04:56:30AM +0900, ara.t.howard@noaa.gov wrote:
On Tue, 23 Jan 2007, Daniel Berger wrote:
which is truly icky!
-a
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama
egads! you are so right. i could have swore i had issue with that.
i stand corrected and retract my suggestion of change!
thanks.
-a
On Tue, 23 Jan 2007 gwtmp01@mac.com wrote:
On Jan 22, 2007, at 2:56 PM, ara.t.howard@noaa.gov wrote:
modifying ri can't address the issue. the issue is that if one types this at
the shell prompt~ > ri String#split
#^^^^^
this is a comment in the __shell__so ri never see anything after the '#'. that's why we have to type
ri 'String#split'
What shell are you using? Bash and ksh seem to accept 'ri String#split'
just fine. I don't think they consider # the start of a comment unless
it is preceded by white space.Gary Wright
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama
sorry dan - i was being an idiot.
-a
On Tue, 23 Jan 2007, Daniel Berger wrote:
First, something is wrong with your ri or your shell, because it works fine
for me. Second, stop using ri and start using fri (fast-ri).
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama