About MyClass#my_method

Hi,

I always see the # notation in the docs to design instance_methods.
Wouldn’t it be nice to be able to use that notation to address and
access methods directly ?

MyClass#my_method would replace MyClass.instance_method(:my_method)

and

def MyClass#my_method end would replace class MyClass; def my_method end
end

Similarily, I was also thinking that :: could be used for class methods.

What do you think ?

The biggest drawback I see actually is that it would impose comments
to have one space before. Like :
MyClass#some comment #=> Error
MyClass #some comment #=> All OK


Cheers,
zimbatm

http://zimbatm.oree.ch

Jonas P. wrote:

Hi,

I always see the # notation in the docs to design instance_methods.
Wouldn’t it be nice to be able to use that notation to address and
access methods directly ?

MyClass#my_method would replace MyClass.instance_method(:my_method)

It has it’s merits. I have to agree, since we use the notation all the
time. But it doesn’t match up with what :: does. And if you change that
you break a lot of code. But IMHO that shouldn;t count it out
neccessarily.

and

def MyClass#my_method end would replace class MyClass; def my_method end end

This is already done:

def MyClass.my_method

Similarily, I was also thinking that :: could be used for class methods.

What do you think ?

The biggest drawback I see actually is that it would impose comments
to have one space before. Like :
MyClass#some comment #=> Error
MyClass #some comment #=> All OK

Prbaby not such a big deal.

I would search the mailing list though, this has been mentioned before.

T.

Hi –

On Fri, 14 Jul 2006, Jonas P. wrote:

def MyClass#my_method end would replace class MyClass; def my_method end end
That syntax is already taken, for comments.

Similarily, I was also thinking that :: could be used for class methods.

I’d be glad to see :: for method calls disappear, but I doubt it
will and therefore it’s not available. Also, both method names and
constants can start with uppercase letters, which I think would make
parsing this impossible.

David

On 14/07/06, removed_email_a[email protected] [email protected] wrote:

Jonas P. wrote:

MyClass#my_method would replace MyClass.instance_method(:my_method)

It has it’s merits. I have to agree, since we use the notation all the
time. But it doesn’t match up with what :: does. And if you change that
you break a lot of code. But IMHO that shouldn;t count it out
neccessarily.

Yes but Matz said to optimize breakage for 2.0 so this might be
worthwile.
I remember that lisp guy saying that ruby methods where not
first-class methods (didn’t find the thread). Which is wrong, but such
shortcuts are nice for metaprogramming.

and

def MyClass#my_method end would replace class MyClass; def my_method end end

This is already done:

def MyClass.my_method

No, this is a class method. You have to use
MyClass.define_method(:my_method) {} to define a new instance method.

I would search the mailing list though, this has been mentioned before.

I’ve tried but nothing really nice went out. Do you have and nice
keywords I could use ?


Cheers,
zimbatm

http://zimbatm.oree.ch

Jonas P. wrote:

Yes but Matz said to optimize breakage for 2.0 so this might be worthwile.
I remember that lisp guy saying that ruby methods where not
first-class methods (didn’t find the thread). Which is wrong, but such
shortcuts are nice for metaprogramming.

I would be even better if they retained state too.

def MyClass#my_method end would replace class MyClass; def my_method end end

This is already done:

def MyClass.my_method

No, this is a class method. You have to use
MyClass.define_method(:my_method) {} to define a new instance method.

Ah, my bad. I misread. Yea, I agree. It would be nice.

I would search the mailing list though, this has been mentioned before.

I’ve tried but nothing really nice went out. Do you have and nice
keywords I could use ?

Hmm. Yea that’s a hard one to search for. I did find this, bt itn;t
much:

http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a5c87a9472c642ce/97c5ede426c1c111?q="%23"+instance+method+ri&rnum=6#97c5ede426c1c111

T.

On 14/07/06, [email protected] [email protected] wrote:

That syntax is already taken, for comments.

I know but other characters are used differently in various
circumstances. For example {} is for a hash or a block depending where
it is in the code.

I would really like that the dot notation would only be used for method
calls.

Similarily, I was also thinking that :: could be used for class methods.

I’d be glad to see :: for method calls disappear, but I doubt it
will and therefore it’s not available. Also, both method names and
constants can start with uppercase letters, which I think would make
parsing this impossible.

Yeah this is a good argument. Actually, the edge case would be when
you have a method and a constant with the same name and that you want
to access to the method’s instance. Like :

class Test end
def Test::LibPath; “.” end
Test::LibPath = File.dirname(FILE)

Test::LibPath would always give the dirname of FILE. But in that
case you could use Test.method(:LibPath)

If you want to call that method, you would alread do Test.LibPath like
in the actual ruby implementation.

The def keywork would allow to make the distinction while parsing.


Cheers,
zimbatm

http://zimbatm.oree.ch

[email protected] wrote:

MyClass#my_method would replace MyClass.instance_method(:my_method)
will and therefore it’s not available. Also, both method names and
constants can start with uppercase letters, which I think would make
parsing this impossible.

We already have theat ambiguity though. That’s why we have to append ()
when calling capitalize methods.

T.

Hi –

On Fri, 14 Jul 2006, Jonas P. wrote:

def MyClass#my_method end would replace class MyClass; def my_method end
end

That syntax is already taken, for comments.

I know but other characters are used differently in various
circumstances. For example {} is for a hash or a block depending where
it is in the code.

OK, then let me put it differently: repurposing comment syntax is a
bad idea :slight_smile: I really think that comments are important enough that
they deserve a completely unchallenged syntax. (I know about “#{}”.
I consider the quotation marks a mitigating factor: “#” wouldn’t be a
comment anyway.)

Yeah this is a good argument. Actually, the edge case would be when
you have a method and a constant with the same name and that you want
to access to the method’s instance. Like :

class Test end
def Test::LibPath; “.” end
Test::LibPath = File.dirname(FILE)

Test::LibPath would always give the dirname of FILE. But in that
case you could use Test.method(:LibPath)

So you’d have to know whether there was a method of the same name…
which I think is very fragile.

David

On 14/07/06, [email protected] [email protected] wrote:

I know but other characters are used differently in various
circumstances. For example {} is for a hash or a block depending where
it is in the code.

OK, then let me put it differently: repurposing comment syntax is a
bad idea :slight_smile: I really think that comments are important enough that
they deserve a completely unchallenged syntax. (I know about “#{}”.
I consider the quotation marks a mitigating factor: “#” wouldn’t be a
comment anyway.)

Yeah your point is really valid :slight_smile: Nonetheless, how often do you
think that there is a def keywork, a class and right after, with no
space, a # with some comment in all the project’s ruby code ? I guess
not that much.

class Test end
def Test::LibPath; “.” end
Test::LibPath = File.dirname(FILE)

Test::LibPath would always give the dirname of FILE. But in that
case you could use Test.method(:LibPath)

So you’d have to know whether there was a method of the same name…
which I think is very fragile.

I don’t know. A method access (in contrary to method call) is already
pretty specific, plus camel cases methods are also pretty specific. If
you do something like this, you would take care isn’t it ? But again,
it’s just an idea. I’m pretty sure it will not be adopted but I like
to discuss about it :slight_smile:


Cheers,
zimbatm

http://zimbatm.oree.ch

Hi –

On Sat, 15 Jul 2006, Jonas P. wrote:

Yeah your point is really valid :slight_smile: Nonetheless, how often do you
think that there is a def keywork, a class and right after, with no
space, a # with some comment in all the project’s ruby code ? I guess
not that much.

It doesn’t matter. There’s no time limit: comments should have their
own syntactic space, forever, whether people use them for a particular
purpose or not.

I don’t know. A method access (in contrary to method call) is already
pretty specific, plus camel cases methods are also pretty specific. If
you do something like this, you would take care isn’t it ? But again,
it’s just an idea. I’m pretty sure it will not be adopted but I like
to discuss about it :slight_smile:

I’m not sure what you mean by “specific” – I’m thinking of a case
where I said:

Something::Whatever

thinking I would get a method object, but in the Something module
there was a Whatever constant. I don’t want to have to check all the
constant and method names dynamically to find out.

David

Nobody else want to join the discussion ?


Cheers,
zimbatm

http://zimbatm.oree.ch

[email protected] wrote:

bad idea :slight_smile: I really think that comments are important enough that
own syntactic space, forever, whether people use them for a particular

which I think is very fragile.
Something::Whatever

thinking I would get a method object, but in the Something module
there was a Whatever constant. I don’t want to have to check all the
constant and method names dynamically to find out.

But I would think this would be sufficient in the cases of capitalized
methods:

Something::Whatever()

Personaly I find the whole notation Class#method pretty poor since it
can’t be used in the langauge itself. I mean, I’ve gotten used to it,
but that doesn’t change the fact. And if comments are a problem with
implementation then maybe we should have a better notation. But that
means a seachange and so when you way the options, I think requiring
a space before an in line comment isn;t so bad --after all were about
to require a space for hash symbol key notation with symbol values.

T.

“Jonas P.” [email protected] writes:

I remember that lisp guy saying that ruby methods where not
first-class methods (didn’t find the thread). Which is wrong, but such
shortcuts are nice for metaprogramming.

Assuming you mean me, I dare you call me a “lisp guy”. Thank you. :wink:

I don’t think instance_method is used often enough to justify it’s own
syntax.

On 15/07/06, Christian N. [email protected] wrote:

Assuming you mean me, I dare you call me a “lisp guy”. Thank you. :wink:

Hehe, no it’s not you. I’m looking in ruby-talk but can’t seem to find
that thread again.

I don’t think instance_method is used often enough to justify it’s own
syntax.

Maybe because it’s too tedious to use ? :wink:


Cheers,
zimbatm

http://zimbatm.oree.ch

Christian N. wrote:

I don’t think instance_method is used often enough to justify it’s own
syntax.

There would be a difference actually.

irb(main):004:0> String.instance_method(:each).object_id
=> -605575968
irb(main):005:0> String.instance_method(:each).object_id
=> -605598168

vs.

irb(main):004:0> String#each.object_id
=> -605575968
irb(main):005:0> String#each.object_id
=> -605575968

Although maybe instance_method should do that anyway?

T.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs