> I agree that `funcall' is a weird name... "call a function". What
> function? I thought we agreed on calling them methods!
I think the idea is that calling methods without a receiver can be
considered "functional style"; therefore, "funcall", rather than
"send", should be understood to include private methods.
I'm not sure I find it very convincing. I think of the no-receiver
thing as a way of un-cluttering the code a bit, not a departure from
object orientation. After all, there *is* a receiver, and it is
receiving a message.
Also, funcall itself does involve a receiver. So the situation is
that you see this:
obj.funcall(:meth)
and you infer that it includes private methods because *if* you were
calling meth as a private method, there would be no receiver. To me
that involves too much "What if?"
>* Oh, and lets not forget the forever arguable method name for (class
><< self; self; end). But please give us something concise.
Yes, the name is the biggest obstacle now.
I take it you don't like meta_class, the most often proposed name for it. How about virtual_class, or singleton_class, or both?
irb(main):001:0> a=5; def a.foo; end
TypeError: can't define singleton method "foo" for Fixnum
from (irb):1
irb(main):002:0> a=""; class Foo < (class << a; self end); end
TypeError: can't make subclass of virtual class
from (irb):2
Devin
(Sorry, I don't know what's already been proposed. Shame on me for not researching it...)
Just about every word in the English language, and a couple in German,
has been proposed
The main thing is that it creates an exception b/c we are forced to use
a reciever, eg. self.class, so it can't be called as a "function" nor
made private. No other method is like that.
Actually, two classes of method names come to mind:
- Those that share a name with a keyword (class, when, def, etc.)
- Setter methods (/=$/, that is)
There's an exception for the latter -- when private, they can be called with self as an explicit receiver.
Neither defending the behavior nor arguing for a change... just playing Mr. Fact Checker (or Mr. Obvious, depending on your POV).
I take it you don't like meta_class, the most often proposed name for
it. How about virtual_class, or singleton_class, or both?
It's not really a meta class since it's not only for classes,
nor virtual_class since it's not virtual anymore.
In my mindset, two candidates have survived. singleton_class (or
singletonclass), which can easily be confused with a class in the
singleton design pattern. And eigenclass, which is unfamiliar for
most people.
matz.
···
In message "Re: Little Things" on Mon, 1 Jan 2007 05:42:23 +0900, Devin Mullins <twifkak@comcast.net> writes:
(Sorry, I don't know what's already been proposed. Shame on me for not
researching it...)
For what it's worth, I started a wiki page a while ago (and others have
contributed) with the crazy huge list of suggested names, with some
discussion on some of them:
I'd like to see them as separated RCRs, even though the new RCR site
have not seen its successful start-up yet.
If the RCR process gets fixed I would be happy to do some of them.
Right now only two people have submitted RCRs (last I checked) and the
communication on those RCRs is either broken or simply not being used
--I made attempts at emailing on the second --and I sumbitted the first
Can you tell me what happened when you tried the email? Did you
subscribe to it at the site? If something's wrong, I can't fix it
unless I hear about it. If people are just not using the site much,
that's not the same as its being broken.
Yikes, a method that behaves differently depending on how it's called? What about method(:send).call vs self.method(:send).call?
Meprefers send_priv or something.
Devin
(And I think David was just trying to guess at the reasoning behind the name "funcall" [I'd imagine better explained by rb_funcall], and then disagreeing with the reasoning.)
> Yukihiro Matsumoto wrote:
>> >* Oh, and lets not forget the forever arguable method name for (class
>> ><< self; self; end). But please give us something concise.
>>
>> Yes, the name is the biggest obstacle now.
> I take it you don't like meta_class, the most often proposed name for it. How
> about virtual_class, or singleton_class, or both?
>
> irb(main):001:0> a=5; def a.foo; end
> TypeError: can't define singleton method "foo" for Fixnum
> from (irb):1
> irb(main):002:0> a=""; class Foo < (class << a; self end); end
> TypeError: can't make subclass of virtual class
> from (irb):2
>
>
>
> Devin
> (Sorry, I don't know what's already been proposed. Shame on me for not
> researching it...)
Just about every word in the English language, and a couple in German,
has been proposed
Trans wrote:
> The main thing is that it creates an exception b/c we are forced to use
> a reciever, eg. self.class, so it can't be called as a "function" nor
> made private. No other method is like that.
Actually, two classes of method names come to mind:
- Those that share a name with a keyword (class, when, def, etc.)
That's a good point. Although 'when', 'def' and others aren't also
built-in methods. And in a private context at least, no one is going to
readily use them as such.
- Setter methods (/=$/, that is)
There's an exception for the latter -- when private, they can be called
with self as an explicit receiver.
True. An expection I never liked, but it's neccessary, and at least
it's a very simple pattern.
Neither defending the behavior nor arguing for a change... just playing
Mr. Fact Checker (or Mr. Obvious, depending on your POV).
>I take it you don't like meta_class, the most often proposed name for
>it. How about virtual_class, or singleton_class, or both?
It's not really a meta class since it's not only for classes,
nor virtual_class since it's not virtual anymore.
In my mindset, two candidates have survived. singleton_class (or
singletonclass), which can easily be confused with a class in the
singleton design pattern. And eigenclass, which is unfamiliar for
most people.
I don't think the "singleton" confusion is a big problem. I've heard
many people say that it might be confusing, but very few people
actually be confused by it. And if they are, it's worth the three
seconds it takes them to learn the difference
Also, unless we're supposed to start using the term "eigenmethod" for
singleton methods, singleton_class is a better match in that sense.
David
···
On Mon, 1 Jan 2007, Yukihiro Matsumoto wrote:
In message "Re: Little Things" > on Mon, 1 Jan 2007 05:42:23 +0900, Devin Mullins <twifkak@comcast.net> writes:
>I take it you don't like meta_class, the most often proposed name for
>it. How about virtual_class, or singleton_class, or both?
It's not really a meta class since it's not only for classes,
nor virtual_class since it's not virtual anymore.
I wonder: is it a mistake to think of it as a class at all? Sure, it had a 'class' somewhere in its background, but is potentially moved on a lot since then. In a way, it's move analogous to a meta-binding, as it's the execution environment of an object. So, just to get the creative juices flowing, and in the spirit of brainstorming, how about
I'm all for eigenclass. Let's have some personnality and impose our own
concepts. And by using an uncommon term like this one, we have the advantage
to be able to define it like we want in the computer domain.
In message "Re: Little Things" > on Mon, 1 Jan 2007 05:42:23 +0900, Devin Mullins <twifkak@comcast.net> > writes:
>I take it you don't like meta_class, the most often proposed name for
>it. How about virtual_class, or singleton_class, or both?
It's not really a meta class since it's not only for classes,
nor virtual_class since it's not virtual anymore.
In my mindset, two candidates have survived. singleton_class (or
singletonclass), which can easily be confused with a class in the
singleton design pattern. And eigenclass, which is unfamiliar for
most people.
I wonder: is it a mistake to think of it as a class at all? Sure, it
had a 'class' somewhere in its background, but is potentially moved
on a lot since then. In a way, it's move analogous to a meta-binding,
as it's the execution environment of an object. So, just to get the
creative juices flowing, and in the spirit of brainstorming, how about
obj.personality
obj.capability
obj.implementation
The "implemantation" is not what we're talking about.
The "personality" and "capability" of an object are characteristics of
the object, combined from attributes of its class and superclasses.
"That something" here is not these characteristics themselves, but a
handle to tweak them by per object basis. Calling a handle by
characteristics may cause confusion.
matz.
···
In message "Re: Little Things" on Mon, 1 Jan 2007 23:38:57 +0900, Dave Thomas <dave@pragprog.com> writes:
In message "Re: Little Things" on Mon, 1 Jan 2007 22:31:06 +0900, dblack@wobblini.net writes:
I don't think the "singleton" confusion is a big problem. I've heard
many people say that it might be confusing, but very few people
actually be confused by it. And if they are, it's worth the three
seconds it takes them to learn the difference
Also, unless we're supposed to start using the term "eigenmethod" for
singleton methods, singleton_class is a better match in that sense.
I wonder: is it a mistake to think of it as a class at all? Sure, it
had a 'class' somewhere in its background, but is potentially moved
on a lot since then. In a way, it's move analogous to a meta-binding,
as it's the execution environment of an object. So, just to get the
creative juices flowing, and in the spirit of brainstorming, how about
obj.personality
obj.capability
obj.implementation
That's an great perspective. Perhaps even different enough to get us
out of this quagmire.
Seems to me that 80% of the time we want to use the "singleton class"
with class_eval. Expressions like "singleton_class.class_eval" are
rather redundant and long winded (IMHO). So maybe another single term
for this, along the lines of what you're saying, would be better.
Looking at Phrogz' wiki page of names I came up with:
customize do
...
end
Then the class could be called the 'customization'. Ie. the above being
equvalent to:
>
> >I take it you don't like meta_class, the most often proposed name for
> >it. How about virtual_class, or singleton_class, or both?
>
> It's not really a meta class since it's not only for classes,
> nor virtual_class since it's not virtual anymore.
I wonder: is it a mistake to think of it as a class at all? Sure, it
had a 'class' somewhere in its background, but is potentially moved
on a lot since then. In a way, it's move analogous to a meta-binding,
as it's the execution environment of an object. So, just to get the
creative juices flowing, and in the spirit of brainstorming, how about
obj.personality
obj.capability
obj.implementation
Cheers
Dave
--
Chris Carter
concentrationstudios.com
brynmawrcs.com
On 12/31/06, Rob Sanheim <rsanheim@gmail.com> wrote:
On 12/31/06, Devin Mullins <twifkak@comcast.net> wrote:
> Trans wrote:
> > Hmm... Are you perhpas indirectly suggesting:
> >
> > send(:meth) # private
> > self.send(:meth) # public
> >
> > ?
>
> Yikes, a method that behaves differently depending on how it's called?
> What about method(:send).call vs self.method(:send).call?
>
> Meprefers send_priv or something.
>
> Devin
What about:
obj.send(:foo) # will call only public
obj.send!(:foo) # will bypass private/protected, like the current send.
