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