Is it considered Harmful?

[rolo]

Hi

obj.class = MyClass

Is it harmful?

rolo

 

[Sean O'Dell]

Hi

obj.class = MyClass

Is it harmful?

irb(main):002:0> {}.class = Array
NoMethodError: undefined method `class=' for {}:Hash
from (irb):2
irb(main):003:0>



Sean O'Dell

 

[Jeff Mitchell]

Hi

obj.class = MyClass

Is it harmful?

rolo

I don't know -- is NoMethodError considered harmful?

If you are so inclined, http://evil.rubyforge.org has an
implementation of Object#class=






__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

 

[Eric Hodel]

--H7BnLk9CMipoMykF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

=20
irb(main):002:0> {}.class =3D Array
NoMethodError: undefined method `class=3D' for {}:Hash
from (irb):2
irb(main):003:0>

Even if there was a #class=3D for objects, it ranks up there with goto in
limited usefulness. Yes, it can be useful, but if you're using it,
you're probably being too clever.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--H7BnLk9CMipoMykF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFA22RnMypVHHlsnwQRAs3zAKCCOv2kRP4spvXCMnGQqykdfGWGqACfc1sE
BgGcIuC6tY+nNvMUjeAjT6Y=
=h++s
-----END PGP SIGNATURE-----

--H7BnLk9CMipoMykF--

 

[rolo]

Even if there was a #class= for objects, it ranks up there with goto in
limited usefulness. Yes, it can be useful, but if you're using it,
you're probably being too clever.

I knew it was evil, I think it should be norm.

PS I know it is not allowed, but is it so for tech reasons?

Regards,
Rohit

 

[Sean O'Dell]

I knew it was evil, I think it should be norm.

PS I know it is not allowed, but is it so for tech reasons?

Good question. I am personally having trouble thinking of a good reason why a
programmer couldn't change the class of an object. Except for possible
problems when a different set of methods suddenly gets a set of instance
variables it might not expect (buyer beware), it seems like we ought to be
able to do that. I don't believe there's any solid technical block to doing
this, is there?

Sean O'Dell

 

[Gennady]

Good question. I am personally having trouble thinking of a good reason why a
programmer couldn't change the class of an object. Except for possible
problems when a different set of methods suddenly gets a set of instance
variables it might not expect (buyer beware), it seems like we ought to be
able to do that. I don't believe there's any solid technical block to doing
this, is there?

Sean O'Dell

It would be nice to have in real life too. Just imagine: you hold an
apple in your hand and suddenly it turns into a piece of gold. I would
not mind ;-)

Gennady.

 

[Lennon Day-Reynolds]

That's exactly the problem -- by forcing one object into another
class, you require that one or both classes have sufficient knowledge
of the internal data representation of the other to be able to safely
make the switch. That kind of low-level manipulation usually stays
within a class for a reason.

The only real reason I can see to dynamically change the class of an
object would be in languages where there are static type constraints
that have to be satisfied. As it is, in Ruby, you can always just wrap
the original object in a proxy, or access it through an adapter that
supports all the public methods of the new class; it fits the "duck
typing" rule, without breaking encapsulation.

Lennon

 

[ts]

S> variables it might not expect (buyer beware), it seems like we ought to be
S> able to do that. I don't believe there's any solid technical block to doing
S> this, is there?

If you think that the possiblity to crash ruby is not a technical reason,
then you are right it don't exist solid technical reason.


Guy Decoux

 

[Scott Rubin]

I can't possibly imagine it being useful to do this except when the
objects have very similar, if not identical, instance variables. And in
cases where this is true we have these things we call polymorphism and
inheritance. Lets say you have a parent class of animal with two
subclasses cat and dog. But both cat and dog have the same data. Name,
gender, breed, color, etc. There should never be a need to turn a cat
into a dog or vice versa. If you are programming properly you would only
deal in objects of type animal. If by some strange change a dog turned
into a cat through genetic engineering you would simply make a new
instance of object cat and copy the data from the former dog object into
it. Then delete the dog object. It is only in this one case that I see
your example being slightly useful, but only for code saving reasons. If
someone else has more insight I would love to hear it.

-Scott

 

[Jim Weirich]

Scott Rubin said:

I can't possibly imagine it being useful to do this except when the
objects have very similar, if not identical, instance variables.

The "standard" application for the self.class= method (aka become(class))
is use it to do demand on load style proxies. Suppose you have a largish
object in external storage (database, file, whatever). You create a
small, efficient proxy item for the large object until you really need the
true data in the object. Then you load the object and let the proxy
"become" the newly loaded object.

Without class=/become methods,
(a) the proxy remains and forwards all messages to the real object, or
(b) you replace every reference in the program to the proxy with
a reference to the real object.

(a) is a small, but anoying constant cost, and (b) may be difficult,
depending on how wide spread the proxy was used.

That's why class=/become would be attractive, despite its technical
difficulties and mildly worrisome semantices.

 

[Michael Walter]

Heya,

That's exactly the problem -- by forcing one object into another
class, you require that one or both classes have sufficient knowledge
of the internal data representation of the other to be able to safely
make the switch. That kind of low-level manipulation usually stays
within a class for a reason.

That's why there are the _generic functions_ CHANGE-CLASS and
UPDATE-INSTANCE-FOR-DIFFERENT-CLASS in Common Lisp.

The only real reason I can see to dynamically change the class of an
object would be in languages where there are static type constraints
that have to be satisfied. As it is, in Ruby, you can always just wrap
the original object in a proxy, or access it through an adapter that
supports all the public methods of the new class; it fits the "duck
typing" rule, without breaking encapsulation.

Another reason would be that it might be useful to change the object _in
place_. That is, all existing references suddenly point to the new object.

Cheers,
Michael

 

[Ara.T.Howard]

Scott Rubin said:

The "standard" application for the self.class= method (aka become(class))
is use it to do demand on load style proxies. Suppose you have a largish
object in external storage (database, file, whatever). You create a
small, efficient proxy item for the large object until you really need the
true data in the object. Then you load the object and let the proxy
"become" the newly loaded object.

Without class=/become methods,
(a) the proxy remains and forwards all messages to the real object, or
(b) you replace every reference in the program to the proxy with
a reference to the real object.

(a) is a small, but anoying constant cost, and (b) may be difficult,
depending on how wide spread the proxy was used.

That's why class=/become would be attractive, despite its technical
difficulties and mildly worrisome semantices.

sounds like an RCR for Object#tie

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Sean O'Dell]

S> variables it might not expect (buyer beware), it seems like we ought to
be S> able to do that. I don't believe there's any solid technical block
to doing S> this, is there?

If you think that the possiblity to crash ruby is not a technical reason,
then you are right it don't exist solid technical reason.

You're wrong on that. It wouldn't crash Ruby to change the class of an
object. Objects already change their class when you turn them into
singletons. Changing it to any class of your choosing would be even simpler,
since creating a singleton involves inheriting all the old class methods;
changing a class wouldn't require all that work.

Sean O'Dell

 

[Sean O'Dell]

That's why class=/become would be attractive, despite its technical
difficulties and mildly worrisome semantices.

I don't think it would be difficult at all. In fact, think of what Ruby has
to go through when you make a class into a singleton with:

obj<<class
end

It has to pull forward all the methods of the object's class into a new
anonymous singleton class for the object. That's a lot more work than simply
pointing the object's class to a different class that's already defined with
all of its methods and such.

It should be very easy to do. I'm wondering if a C extension could possibly
even do this.

Sean O'Dell

 

[Sean O'Dell]

sounds like an RCR for Object#tie

Or class=.

Sean O'Dell

 

[Dave Thomas]

You're wrong on that. It wouldn't crash Ruby to change the class of an
object. Objects already change their class when you turn them into
singletons.
Changing it to any class of your choosing would be even simpler,
since creating a singleton involves inheriting all the old class
methods;
changing a class wouldn't require all that work.

Singletons are effectively subclasses of the original.

irb(main):001:0> a = /cat/
=> /cat/
irb(main):002:0> def a.speak; "meiow"; end
irb(main):005:0> a.speak
=> "meiow"
irb(main):006:0> a.class
=> Regexp

How would you handle
a = /cat/
a.class = File
a.read

It's a brave man that calls Guy 'wrong,' so I'm looking forward to
seeing your implementation of this.

Cheers

Dave

 

[ts]

S> You're wrong on that. It wouldn't crash Ruby to change the class of an

Just search in http://www.ruby-talk.org/

S> object. Objects already change their class when you turn them into
S> singletons. Changing it to any class of your choosing would be even simpler,
S> since creating a singleton involves inheriting all the old class methods;
S> changing a class wouldn't require all that work.

You have just forgotten that a class is an object ...


Guy Decoux

 

[gabriele renzi]

Another reason would be that it might be useful to change the object _in
place_. That is, all existing references suddenly point to the new object.

in evil.rb (you can find it at rubyforge) you even have Object#become
if you need it

 

[ts]

S> It should be very easy to do. I'm wondering if a C extension could possibly
S> even do this.

You are right, a C extension can effectively crash ruby

Read carefully hash.c and array.c and just imagine what will be the result
if one method of hash.c will be applied to an array.

matz has one day say it in a message to ruby-talk : one information is
missing


Guy Decoux