Lookup of Capitalized Methods

Well, silly me, I just realized what I suppose is THE issue with
capitalized methods serving as proxies for modules/classes.

To put it in context, I was working on Parametric mixins, such that
some #Includable() returns Includable after defining the parameters in
“self”. It works great except…

The scope lookup of methods is not the same a constants.

That’s kind of a shame, this is such a useful technique, in my
opinion. Now I would be just as happy to use Includable#[] instead,
but without a Binding.of_caller it is not possible.

So, assuming we are still ideologically opposed binding-of-caller what
do others think of the idea of capitalized methods having the same
scope lookup as constants?

T.

On Fri, Apr 4, 2008 at 4:07 PM, Trans [email protected] wrote:

opinion. Now I would be just as happy to use Includable#[] instead,
but without a Binding.of_caller it is not possible.

So, assuming we are still ideologically opposed binding-of-caller what
do others think of the idea of capitalized methods having the same
scope lookup as constants?

At first sight it is counter intuitive, so I am quite against it. OTOH
Capitalized Methods Are Not Something Used A Lot…
Nevertheless I am afraid of confusion.
Sorry
Robert

T.


http://ruby-smalltalk.blogspot.com/


Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein

On Apr 4, 2008, at 8:07 AM, Trans wrote:

So, assuming we are still ideologically opposed binding-of-caller what
do others think of the idea of capitalized methods having the same
scope lookup as constants?

it leads to a weird sort of namespace pollution:

class C

def M

 'quasi-globa-instance-methodl'

end

class D

 def foobar

   M()  # this works even though M is not an instance method of D

 end

end

end

a @ http://codeforpeople.com/

On Apr 4, 2008, at 9:27 AM, Trans wrote:

Right it does. But it’s not a “pollution” we are unaccustomed to --it
is merely constant lookup. So we can conceive of these as Constant
Methods.

However, you make a point. In having these it would probably require
we enforce that normal methods can not be capitalized. But, as Robert
says, they are rarely used. In fact, I would argue that when they are
used it is probably alwasy to achieve exactly the kind of
functionality this change would support.

it’s more complicated than that:

module M

def Clobber
end

Const = 42

def self.included other

 :nothing

end

end

class C

include M

end

if you want method lookup to behave like constant lookup this would
have to inject the Clobber method into C. this is not widely
appreciated, but ruby injects the constants from a module into a class
on inclusion regardless of any ‘self.included’ hook defined. so to
maintain consistency between methods and constants we’d have to either

A) have the above code cherry-pick caps methods and include them
silently behind our backs

B) Not have constants injected during module inclusion

feels a bit like standing on an icy roof to me…

a @ http://codeforpeople.com/

On Apr 4, 11:01 am, “ara.t.howard” [email protected] wrote:

class C

   M()  # this works even though M is not an instance method of D

 end

end

end

Right it does. But it’s not a “pollution” we are unaccustomed to --it
is merely constant lookup. So we can conceive of these as Constant
Methods.

However, you make a point. In having these it would probably require
we enforce that normal methods can not be capitalized. But, as Robert
says, they are rarely used. In fact, I would argue that when they are
used it is probably alwasy to achieve exactly the kind of
functionality this change would support.

T.

On Apr 4, 12:06 pm, Trans [email protected] wrote:

 Const = 42

 include M

end

Which is essentially the functionality desired, with the one exception
that the same name could be used for a class/module constant and a
method constant – the () would differentiate which is meant.

Actually, there is another exception (and perhaps you were meaning
this?) That ‘self’ within the method would be the execution context,
but with the lambda it is the defining module context. So my example
isn’t as equivalent as I first thought. Too bad… But it does convey
the “constant first” idea I was getting at.

T.

On Apr 4, 11:38 am, “ara.t.howard” [email protected] wrote:

functionality this change would support.
def self.included other

B) Not have constants injected during module inclusion

Hmmm… I don’t think that’s right. These choices assume the viewpoint
that these are methods first, but rather I say they ought to be
constants first.

To give you better idea of what I mean, your example made me think of:

module M

 Clobber = lambda {}

 Const = 42

 def self.included other

   :nothing

 end

end

class C

 include M

end

Which is essentially the functionality desired, with the one exception
that the same name could be used for a class/module constant and a
method constant – the () would differentiate which is meant.

T.

On Apr 4, 2008, at 10:06 AM, Trans wrote:

Hmmm… I don’t think that’s right. These choices assume the viewpoint
that these are methods first, but rather I say they ought to be
constants first.

i have no idea what you mean by ‘these are methods first’…

if you want a constant that acts like a method we simply need to be
able to override ‘()’ as many functional languages, even c++, allow

module M

Const = method ‘foobar’

end

include M

Const()

a @ http://codeforpeople.com/

On Apr 4, 2008, at 10:52 AM, Trans wrote:

Yes, that’s exactly the behavior, and one way, perhaps the best way,
to approach it.

okay

Methods = {
‘foobar’ => method(‘foobar’),
‘barfoo’ => method(‘barfoo’),
}

def method_missing m, *a, &b
case m.to_s
when %r/^[A-Z]/
Methods[m.to_s].call *a, &b
else
super
end
end

may have to handle const_missing too

a @ http://codeforpeople.com/

On Apr 4, 12:40 pm, “ara.t.howard” [email protected] wrote:

On Apr 4, 2008, at 10:06 AM, Trans wrote:

Hmmm… I don’t think that’s right. These choices assume the viewpoint
that these are methods first, but rather I say they ought to be
constants first.

i have no idea what you mean by ‘these are methods first’…

Sorry that wasn’t clear enough. I just wasn’t sure how else to convey
it.

Const()

Yes, that’s exactly the behavior, and one way, perhaps the best way,
to approach it.

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