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
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.
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.
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 ?
···
On 14/07/06, transfire@gmail.com <transfire@gmail.com> 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.
> 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.
···
On 14/07/06, dblack@wobblini.net <dblack@wobblini.net> 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:
> 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.
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.
> 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)
So you'd have to know whether there was a method of the same name...
which I think is very fragile.
David
···
On Fri, 14 Jul 2006, Jonas Pfenniger wrote:
On 14/07/06, dblack@wobblini.net <dblack@wobblini.net> 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.
Assuming you mean me, I dare you call me a "lisp guy". Thank you.
I don't think instance_method is used often enough to justify it's own
syntax.
···
On 14/07/06, transfire@gmail.com <transfire@gmail.com> 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
···
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.
David
···
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.
···
On Sat, 15 Jul 2006, Jonas Pfenniger wrote:
> On 14/07/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
I really think that comments are important enough that