[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Lookup of Capitalized Methods

Trans

4/4/2008 2:07:00 PM

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.

9 Answers

Robert Dober

4/4/2008 2:21:00 PM

0

On Fri, Apr 4, 2008 at 4:07 PM, Trans <transfire@gmail.com> wrote:
> 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?

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

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

ara.t.howard

4/4/2008 3:02:00 PM

0


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://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Trans

4/4/2008 3:27:00 PM

0



On Apr 4, 11:01 am, "ara.t.howard" <ara.t.how...@gmail.com> wrote:
> 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

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.

ara.t.howard

4/4/2008 3:38:00 PM

0


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://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Trans

4/4/2008 4:07:00 PM

0



On Apr 4, 11:38 am, "ara.t.howard" <ara.t.how...@gmail.com> wrote:
> 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

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.

Trans

4/4/2008 4:16:00 PM

0



On Apr 4, 12:06 pm, Trans <transf...@gmail.com> 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.
>
> 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.

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.

ara.t.howard

4/4/2008 4:40:00 PM

0


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://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Trans

4/4/2008 4:52:00 PM

0


On Apr 4, 12:40 pm, "ara.t.howard" <ara.t.how...@gmail.com> 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.

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

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

T.

ara.t.howard

4/4/2008 5:01:00 PM

0


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://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama