OpenStruct#update ?

[David A. Black]

Hi --

On Monday 15 November 2004 08:45 am, David A. Black wrote:
|
| Yeah, as long as he doesn't choose 'virtual'

He he. Seems like all the readily floated possibilities have poor
connotations. I've heard complaints about all three: 'virtual', 'meta', and
of course, 'singleton'. So what do others think of 'instance' class? Or more
to the point 'special' class -- a specialton

In thinking about such things my mind always jumps to the question:
how easy (or not) will it be to explain to people? I think instance
class might be fairly good in that regard, but I'm not sure it's
logical. Why not "object class", since above all everything that has
one is an object? Which also means it's an instance, but why choose
that as its main identity? (Not that I like "object class"; I'm just
not sure that I'm seeing the reasoning behind "instance class".)

I'd also thought of "own class", as in:

obj.class
obj.own_class

(I'd actually prefer #class to be deprecated in favor of #birth_class,
so as to make a clearer pairing of, and distinction between, an
object's two classes. but I do not expect that to happen


David

 

[ts]

D> obj.class
D> obj.own_class

You can rename it, but don't forget to rename

rb_define_singleton_methods()
rb_singleton_class_clone()
etc,

also don't forget this strange T_SINGLETON that sometimes I see in the
doc.



Guy Decoux

 

[ts]

t> also don't forget this strange T_SINGLETON that sometimes I see in the
^^^^^^^^^^^

it's FL_SINGLETON (je suis fatigue :-()

t> doc.

Guy Decoux

 

[George Ogata]

On Monday 15 November 2004 08:45 am, David A. Black wrote:
|
| Yeah, as long as he doesn't choose 'virtual'

He he. Seems like all the readily floated possibilities have poor
connotations. I've heard complaints about all three: 'virtual', 'meta', and
of course, 'singleton'. So what do others think of 'instance' class? Or more
to the point 'special' class -- a specialton

Personal class? (Every object has its own personal class.)

 

[David A. Black]

Hi --

D> obj.class
D> obj.own_class

You can rename it, but don't forget to rename

rb_define_singleton_methods()
rb_singleton_class_clone()
etc,

also don't forget this strange T_SINGLETON that sometimes I see in the
doc.

I'm not planning to rename it myself -- just discussing possible
names. I think it's true that Matz has said he is at least
considering changing it from singleton class to something else. (I
assume he'll search-and-replace if he does so


David

 

[Florian Gross]

D> obj.class
D> obj.own_class

You can rename it, but don't forget to rename

rb_define_singleton_methods()
rb_singleton_class_clone()
etc,

also don't forget this strange T_SINGLETON that sometimes I see in the
doc.

But what about this?

irb(main):001:0> class << 1; end
TypeError: no virtual class for Fixnum

Ruby itself isn't consistent in the terminology it uses. Maybe that is
the bigger problem.

 

[Robert Klemme]

You are right of course. I also like how you moved the attr_accessor out
of the loop -- nice idea.
Thanks!


Hm, I think that would still overwrite methods of o's class and
inherited ones.

I don't think so:
=> true

The singleton class of f knows about instance methods defined in super
classes. Which is logical, considering this:
=> [Foo, Object, Kernel]

What about this?

accessors = h.keys - o.methods
class << o; self; end.sendattr_accessor, *accessors)
h.each do |key, value|
o.send("#{key}=", value) if accessors.include?(key)
end

Nice and short. But it has some drawbacks:

(with f and Foo as above)

h={:foo=>"foo", :bar=>"bar"} => {:foo=>"foo", :bar=>"bar"}
h.keys-f.methods => [:foo, :bar]
h.keys

=> [:foo, :bar]

You would want ":bar" removed from the keys but it isn't because f.methods
returns an array of String. (I assume that symbols are the most likely
keys for the hash - which might be wrong.)

Plus, it's not selective enough IMHO because if you just have a setter,
then that is overwritten. And if you just have a getter, then no setter
is defined and you get an error during o.send("#{key}="...).

Kind regards

robert

 

[Robert Klemme]

On Monday 15 November 2004 07:38 am, Robert Klemme wrote:
| |
| > trans. (T. Onoma) wrote:
| > > Sure. Okay first, basically what I was doing, given object o and data
|
| in hash
|
| > > h:
| > >
| > > h.each do |k,v|
| > > o.instance_variable_set("@#{k}", v)
| > > o.instance_eval <<-EOS
| > > def #{k}; @#{k}; end
| > > def #{k}=(x); @#{k}=x; end
| > > EOS
| > > end
| >
| > h.each do |k,v|
| > class << o; self; end.sendattr_accessor, k)
| > o.k = v
| > end
|
| Are you sure, this works? IMHO this is more efficient:

Actually the example is pulled inside out from the real method I use which is
a method of class Object (where it does work). So no the above probably
doesn't work as give --but was just intended to give approx. notion of what
I'm doing.

I mean't Florian's code not yours. Sorry if that hasn't become clear
'nough.

| class << o; self; end.sendattr_accessor, *h.keys)
| h.each do |k,v|
| o.send("#{k}=", v)
| end
|
| But it would be even better to check for existing methods in order to not
| overwrite existing methods:
|
| cl = class << o; self; end
| im = cl.instance_methods
| h.each do |k,v|
| cl.sendattr_reader, k) unless im.include?(k.to_s)
| cl.sendattr_writer, k) unless im.include?("#{k}=")
| o.send("#{k}=", v)
| end

I'm not sure I want that. Hmm... It's a sticky issue depending largely on the
particular use case. I think it makes sense for general use, so yes --I'll
add something like that, thanks. Should it raise an error instead?

But in the context of an OpenStruct, no. OpenStruct focus is on data.

Full ACK.

Kind regards

robert

 

[Robert Klemme]

Hi --



In thinking about such things my mind always jumps to the question:
how easy (or not) will it be to explain to people? I think instance
class might be fairly good in that regard, but I'm not sure it's
logical. Why not "object class", since above all everything that has
one is an object? Which also means it's an instance, but why choose
that as its main identity? (Not that I like "object class"; I'm just
not sure that I'm seeing the reasoning behind "instance class".)

I'd also thought of "own class", as in:

obj.class
obj.own_class

What about obj.my_own_class? Ok, just kidding...

(I'd actually prefer #class to be deprecated in favor of #birth_class,
so as to make a clearer pairing of, and distinction between, an
object's two classes. but I do not expect that to happen

So am I.

Cheers

robert

 

[Florian Gross]

The singleton class of f knows about instance methods defined in super
classes. Which is logical, considering this:

Ah, I was confusing instance_methods() with instance_methods(false).

accessors = h.keys - o.methods
class << o; self; end.sendattr_accessor, *accessors)
h.each do |key, value|
o.send("#{key}=", value) if accessors.include?(key)
end

Nice and short. But it has some drawbacks:
[...]

You would want ":bar" removed from the keys but it isn't because f.methods
returns an array of String. (I assume that symbols are the most likely
keys for the hash - which might be wrong.)

Hm, I assumed the hash would contain Strings as keys. I guess it could
be normalized to that.

Plus, it's not selective enough IMHO because if you just have a setter,
then that is overwritten. And if you just have a getter, then no setter
is defined and you get an error during o.send("#{key}="...).

I was trying to work around methods in Kernel -- I don't think it makes
sense to have o.p = when you don't have o.p. But I guess the check isn't
strictly needed anyway. (attr_accessor will create a public getter. I
thought it would create a private one.)

 

[ts]

F> But what about this?

Why do you think that, one day, I've said to someone that he must be
carefull with "singleton class" if he want to document ruby ?



Guy Decoux

 

[trans. (T. Onoma)]

On Monday 15 November 2004 09:04 am, David A. Black wrote:
| (I'd actually prefer #class to be deprecated in favor of #birth_class,
| so as to make a clearer pairing of, and distinction between, an
| object's two classes.  but I do not expect that to happen

#object_class (like #object_id) would be nice. Then #class could be used by us
end programmers.

T.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Kernel#singleton_class"

|But what about this?
|
|irb(main):001:0> class << 1; end
|TypeError: no virtual class for Fixnum

It was an old message reflected the model (once in my brain) in which
"class <<obj; end" actually generated the "virtual class" to hold
singleton methods etc. temporarily, then update the internal singleton
data structure. I will fix the message.

|Ruby itself isn't consistent in the terminology it uses. Maybe that is
|the bigger problem.

Indeed.

matz.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Kernel#singleton_class"

|> I guess it's probably best to let matz decide the name.
|
|Yeah, as long as he doesn't choose 'virtual'

I'd call them singleton classes. Any objection?

matz.

 

[trans. (T. Onoma)]

On Monday 15 November 2004 12:28 pm, Yukihiro Matsumoto wrote:
| Hi,
|
| In message "Re: Kernel#singleton_class"
|
| on Mon, 15 Nov 2004 22:45:31 +0900, "David A. Black"
| |> I guess it's probably best to let matz decide the name.
| |
| |Yeah, as long as he doesn't choose 'virtual'
|
| I'd call them singleton classes. Any objection?
|
| matz.

Yes, cause of singleton pattern.

T.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Kernel#singleton_class"

|| I'd call them singleton classes. Any objection?

|Yes, cause of singleton pattern.

Hmm, any other alternative?

I don't prefer the terms "instance class" and "object class", just
because it's meaningless. Classes are naturally corresponding to
objects (or instances) in OOP. Besides, the word singleton used from
Lisp era, way older than design patterns, IIRC.

matz.

 

[Florian Gross]

On Monday 15 November 2004 12:28 pm, Yukihiro Matsumoto wrote:
| I'd call them singleton classes. Any objection?
|
| matz.

Yes, cause of singleton pattern.

Objection to the objection: The singleton pattern is not widely used in
Ruby. Couldn't we rename the implementation of it? Maybe something like
"SingleInstanceClass"?

 

[Hal Fulton]

On Monday 15 November 2004 12:28 pm, Yukihiro Matsumoto wrote:
| Hi,
|
| In message "Re: Kernel#singleton_class"
|
| on Mon, 15 Nov 2004 22:45:31 +0900, "David A. Black"
| |> I guess it's probably best to let matz decide the name.
| |
| |Yeah, as long as he doesn't choose 'virtual'
|
| I'd call them singleton classes. Any objection?
|
| matz.

Yes, cause of singleton pattern.

This doesn't bother me. We will almost always have the word "class"
or "pattern" following the word "singleton." No ambiguity. We do
sometimes talk about a Singleton (without the word "pattern"), but
then it is always capitalized.

There are also singleton methods; and I think some people refer to
objects that possess singleton methods as singletons. However, it's
always possible to clarify your meaning by the simple addition of
a single word.

I think the important thing is to know the meaning of the word
"singleton"; and then its specific meaning in context will be made
clear. (FWIW, it's used in card games also.)


Hal

 

[trans. (T. Onoma)]

On Monday 15 November 2004 01:18 pm, Yukihiro Matsumoto wrote:
| Hi,
|
| In message "Re: Kernel#singleton_class"
|
| on Tue, 16 Nov 2004 02:54:13 +0900, "trans. (T. Onoma)"
| || I'd call them singleton classes. Any objection?
| |
| |Yes, cause of singleton pattern.
|
| Hmm, any other alternative?
|
| I don't prefer the terms "instance class" and "object class", just
| because it's meaningless. Classes are naturally corresponding to
| objects (or instances) in OOP. Besides, the word singleton used from
| Lisp era, way older than design patterns, IIRC.

Interesting. I didn't know that. I wouldn't normally object but I've seen
discussion confusion over this more times than I can count. As for something
meaningful, the word 'special', as in specialized, again comes to mind.

Merriam-Webster Entry
Entry Word: special
Function: adjective
Text: 1 of or relating to one thing or class

-T.

 

[Florian Gross]

dedicated_class
owned_class
private_class
individual_class
individualized_class
personal_class
personalized_class

Sorry, I was talking about the pattern that lets you only create a
single instance of a class. See singleton.rb in Ruby's standard library.

Heh, I just did a quick Google search for "singleton.rb" to see where it
is being used and found that there's already an RCR for renaming it on
http://www.rcrchive.net/rcr/show/246