[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

About MyClass#my_method

zimba.tm@gmail.com

7/14/2006 9:16:00 AM

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://zimba...
14 Answers

Trans

7/14/2006 10:58:00 AM

0


Jonas Pfenniger 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.

dblack

7/14/2006 11:24:00 AM

0

zimba.tm@gmail.com

7/14/2006 12:50:00 PM

0

On 14/07/06, transfire@gmail.com <transfire@gmail.com> wrote:
> Jonas Pfenniger 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.

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

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

--
Cheers,
zimbatm

http://zimba...

Trans

7/14/2006 1:05:00 PM

0


Jonas Pfenniger 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=%22%23%22+instance+method+ri&rnum=6#97c5ed...

T.

Trans

7/14/2006 1:07:00 PM

0


dblack@wobblini.net wrote:
> Hi --
>
> On Fri, 14 Jul 2006, Jonas Pfenniger 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)
> >
> > 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.

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

T.

zimba.tm@gmail.com

7/14/2006 1:17:00 PM

0

On 14/07/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
> On Fri, 14 Jul 2006, Jonas Pfenniger wrote:
> > 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
>
> 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://zimba...

dblack

7/14/2006 2:21:00 PM

0

zimba.tm@gmail.com

7/14/2006 4:44:00 PM

0

On 14/07/06, dblack@wobblini.net <dblack@wobblini.net> 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 :-) 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.

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

--
Cheers,
zimbatm

http://zimba...

dblack

7/14/2006 4:59:00 PM

0

Trans

7/15/2006 4:07:00 PM

0


dblack@wobblini.net wrote:
> Hi --
>
> On Sat, 15 Jul 2006, Jonas Pfenniger wrote:
>
> > On 14/07/06, dblack@wobblini.net <dblack@wobblini.net> 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 :-) 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.
>
> 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.
>
> >> > 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 :-)
>
> 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.