From: Marc Heiler <lists@...>
Date: 2012-10-25T03:01:10+09:00
Subject: Re: Calling a method foo() or an object foo.method_call_here - both

Yes, if I have to use:

  f.method_name()

Then there is no real advantage.

It would have to be via

  method_name

> Well, you cannot have all at once. If you don't want to change
> the source code of Ruby, you have to make compromises.

I am fine with this. I just want to verify that there is
no alternative to what I want.

> Either the calling syntax will change, or you'll have to
> prepend the object name.

I understand that now. Looks as if I can not get this
feature then. :(

> But like I already said, this whole idea is rather strange.
> What's the actual use case?

I have a few methods in a project that can only be
called via:

  name

They all accept the "same" arguments though. Not the
same arguments of course, actually, but the name of
the arguments is the same. For example:

  def foo(css_class = nil, css_style = nil, object_id = nil)

  end

By default, none of these arguments is mandatory. (There
are also lots more arguments to these methods, and block
usage via yield too, but I simplified it to keep it
simpler, to demonstrate)

What I want to have is the ability to easily change
all these methods BUT only if I specifically do so,
by accessing the name of the method.

For instance, the *perfect* syntax would then actually
be this here:

  foo.css_class = 'red'

^^^ That would be perfect if that could work! But of
course you can not change default parameters in methods
so easily. :(

I'd love to be able to access them like data structures
on objects.

> Isn't there a better solution that doesn't involve
> messing with core functionalities of the language?

If you have an idea with shorter syntax, sure. But
all proposals so far required longer syntax. I don't
really seek something that is longer than what I want
because I know how to solve that already (or perhaps
you know of an elegant way, I have not explored
everything - perhaps there is a solution with procs,
but they are kind of mysterious to me).

> If you find yourself using a lot of global methods,
> I think there's generally something wrong.

That is unspecific. I don't know what to do with such
a general statement. :)

Do you have a specific suggestion for a shorter
solution?

The methods are not really "global", they all reside
in a module, and that module is pulled in when the
project is required.

There is no way I will change this project to require
the leading "foo." ever, because that would inflate
the whole code of my project by +100% for no net gain
at all.

-- 
Posted via http://www.ruby-forum.com/.