About MyClass#my_method

[Jonas Pfenniger]

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_methodmy_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

 

[transfire]

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_methodmy_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.

 

[dblack]

Hi --

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_methodmy_method)

and

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

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
(e-mail address removed) => me

 

[Jonas Pfenniger]

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.

This is already done:

def MyClass.my_method
...

No, this is a class method. You have to use
MyClass.define_methodmy_method) {} to define a new instance method.

Prbaby not such a big deal.

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 ?

 

[transfire]

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.

No, this is a class method. You have to use
MyClass.define_methodmy_method) {} to define a new instance method.

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

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...#"+instance+method+ri&rnum=6#97c5ede426c1c111

T.

 

[transfire]

Hi --



That syntax is already taken, for comments.


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.

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

T.

 

[Jonas Pfenniger]

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.

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.methodLibPath)

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.

 

[dblack]

Hi --

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 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.)

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


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.methodLibPath)

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


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
(e-mail address removed) => me

 

[Jonas Pfenniger]

OK, then let me put it differently: repurposing comment syntax is a
bad idea 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 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.

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

 

[dblack]

Hi --

Yeah your point is really valid 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

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

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
(e-mail address removed) => me

 

[Trans]

Hi --



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'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.

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 Pfenniger]

Nobody else want to join the discussion ?

 

[Jonas Pfenniger]

Assuming you mean me, I dare you call me a "lisp guy". Thank you. ;-)

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 ? ;-)

 

[transfire]

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_methodeach).object_id
=> -605575968
irb(main):005:0> String.instance_methodeach).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.