[#1263] Draft of the updated Ruby FAQ — Dave Thomas <Dave@...>

33 messages 2000/02/08

[#1376] Re: Scripting versus programming — Andrew Hunt <andy@...>

Conrad writes:

13 messages 2000/02/15

[#1508] Ruby/GTK and the mainloop — Ian Main <imain@...>

17 messages 2000/02/19
[#1544] Re: Ruby/GTK and the mainloop — Yasushi Shoji <yashi@...> 2000/02/23

Hello Ian,

[#1550] Re: Ruby/GTK and the mainloop — Ian Main <imain@...> 2000/02/23

On Wed, Feb 23, 2000 at 02:56:10AM -0500, Yasushi Shoji wrote:

[#1516] Ruby: PLEASE use comp.lang.misc for all Ruby programming/technical questions/discussions!!!! — "Conrad Schneiker" <schneiker@...>

((FYI: This was sent to the Ruby mail list.))

10 messages 2000/02/19

[#1569] Re: Ruby: constructors, new and initialise — Yukihiro Matsumoto <matz@...>

The following message is a courtesy copy of an article

12 messages 2000/02/25

[ruby-talk:01236] Singleton classes

From: Clemens Hintze <c.hintze@...>
Date: 2000-02-05 07:43:18 UTC
List: ruby-talk #1236
Dave Thomas writes:
> 
> I just _know_ this is going to get me in trouble, but...
> 
> We currently document this construct:
> 
>   class << obj
>      ..
>   end
> 
> as a 'singleton class'. There's some logic to the name, but I was
> wondering... would 'anonymous class' be more understandable?
> 

Hmm! Anonymous class remind me as a class created via 'Class.new'. For
me, this construct is something to *extend* an object. I know the
implementation, but I see it only as a user, and there it seems that
only the object is extended with new capabilities. No new class
anywhere.

So if changing the term, how about object extension?

> After all, what you're doing is creating a new, unnamed class, based on

Yes! But this happens internally and is not obvious to the user of
that construct, is it?

> obj's class. Yes, there's only one of them (initially), so it _is_ a
> singleton, but I personally find the terminology obscure.

Both, the old terminology and your proposed one, it too much in the
hidden internal direction, IMHO. I would call it for what it does, not
how it work internally.

> 
> As we're just starting to get some momentum going on getting a lot
> more English-language Ruby documentation out (more news later), now is
> a good time to have a look at the notation and see if we can find
> areas where terms could be made clearer.

In the past there was a problem with the terms of iterators. matz has
begun to clarify it, but perhaps there are some places where it is
still inconsistent yet? It should be called either block (in source)
or closure (as object) now.

> 
> What do people think? And are there other phrases and concepts that
> people would like to discuss?

Certainly, but I cannot remember right now :-)

...

\cle

-- 
Clemens Hintze  mailto: c.hintze@gmx.net

In This Thread