What is the fastest way to convert a object?

[Magicloud Magiclouds]

Dear all,


Class Test
def methodA
puts(@var1)
end
def initialize
@var1 = 0
end
end

obj = Object.new
obj.instance_variable_set@var1, 2)


# Now I want obj to be Test's instance, so I can
obj.methodA
# How to do this quickly?



Thanks.

 

[Ryan Davis]

Class Test
def methodA
puts(@var1)
end
def initialize
@var1 = 0
end
end

obj = Object.new
obj.instance_variable_set@var1, 2)


# Now I want obj to be Test's instance, so I can
obj.methodA
# How to do this quickly?

You don't. Ruby is strongly typed, which means that things don't just
"morph" into other types of things automatically or manually.
Specifically, you can't (without voodoo) set an instance's class.

 

[Robert Klemme]

You don't. Ruby is strongly typed, which means that things don't just
"morph" into other types of things automatically or manually.
Specifically, you can't (without voodoo) set an instance's class.

Adding to that: MM, what problem are you trying to solve?

robert

 

[Magicloud Magiclouds]

You don't. Ruby is strongly typed, which means that things don't just
"morph" into other types of things automatically or manually.
Specifically, you can't (without voodoo) set an instance's class.

Would obj.extend(Test) work?

 

[Peña, Botp]

From: Magicloud Magiclouds [mailto:[email protected]]=20
# Would obj.extend(Test) work?

ah, module (instead of class) would be good for morhphing (mixin in =
ruby's parlance)

irb(main):003:0> module Test
irb(main):004:1> def methodA
irb(main):005:2> puts @var1
irb(main):006:2> end
irb(main):007:1> def initialize
irb(main):008:2> @var1=3D0
irb(main):009:2> end
irb(main):010:1> end
=3D> nil
irb(main):011:0> obj=3DObject.new
=3D> #<Object:0xb7d5dab0>
irb(main):012:0> obj.instance_variable_set@var1,2)
=3D> 2
irb(main):013:0> obj.extend Test
=3D> #<Object:0xb7d5dab0 @var1=3D2>
irb(main):021:0> obj.methods.grep /^method/
=3D> ["method", "methodA", "methods"]
irb(main):022:0> obj.methodA
2
=3D> nil

kind regards -botp

 

[Magicloud Magiclouds]

Adding to that: MM, what problem are you trying to solve?

robert

I am using DRb, and I have many data models need to be generated on
server and sent to client. So I think a smaller object would be better.
Right?

 

[Peña, Botp]

From: Pe=F1a, Botp [mailto:[email protected]]=20
# irb(main):007:1> def initialize
# irb(main):008:2> @var1=3D0
# irb(main):009:2> end

oops, ignore the init.=20

 

[Magicloud Magiclouds]

From: Magicloud Magiclouds [mailto:[email protected]]
# Would obj.extend(Test) work?

ah, module (instead of class) would be good for morhphing (mixin in ruby's parlance)

irb(main):003:0> module Test
irb(main):004:1> def methodA
irb(main):005:2> puts @var1
irb(main):006:2> end
irb(main):007:1> def initialize
irb(main):008:2> @var1=0
irb(main):009:2> end
irb(main):010:1> end
=> nil
irb(main):011:0> obj=Object.new
=> #<Object:0xb7d5dab0>
irb(main):012:0> obj.instance_variable_set@var1,2)
=> 2
irb(main):013:0> obj.extend Test
=> #<Object:0xb7d5dab0 @var1=2>
irb(main):021:0> obj.methods.grep /^method/
=> ["method", "methodA", "methods"]
irb(main):022:0> obj.methodA
2
=> nil

kind regards -botp

Yes, that is good. Thanks.
I need to try it to see if it is right for me.

 

[Ryan Davis]

I am using DRb, and I have many data models need to be generated on
server and sent to client. So I think a smaller object would be
better. Right?

Wrong. Just do what you need to do in the simplest implementation
possible. Worry about size/bandwidth/other when it actually becomes a
problem. Chances are, it won't. For all you know, you could have been
done by now.

Wait...

What makes you think that Object.new is smaller than Test.new? No.
Just write your code for correctness and stop optimizing stuff you
aren't measuring in the first place. You'll be happier.

 

[Robert Klemme]

I am using DRb, and I have many data models need to be generated on
server and sent to client. So I think a smaller object would be better.
Right?

Maybe, maybe not. Here are my 0.02 EUR:

1. I'd verify that "large" objects are really an issue
2. I'd make conversion explicit by means ot a #to_xyz method, i.e.
receive an object and invoke obj.to_your_real_stuff on it.

Kind regards

robert

 

[Magicloud Magiclouds]

Wrong. Just do what you need to do in the simplest implementation
possible. Worry about size/bandwidth/other when it actually becomes a
problem. Chances are, it won't. For all you know, you could have been
done by now.

Wait...

What makes you think that Object.new is smaller than Test.new? No. Just
write your code for correctness and stop optimizing stuff you aren't
measuring in the first place. You'll be happier.

Yes, thank you.

 

[Magicloud Magiclouds]

Maybe, maybe not. Here are my 0.02 EUR:

1. I'd verify that "large" objects are really an issue
2. I'd make conversion explicit by means ot a #to_xyz method, i.e.
receive an object and invoke obj.to_your_real_stuff on it.

Kind regards

robert

Yes, this is my problem, too.
I need an efficient way to transfer data model, but it seems that drb is
not just "transfer".
Even if I ignore the object size thing, still, calling a drbObject's
complex method is an issue.

 

[Robert Klemme]

Yes, this is my problem, too.
I need an efficient way to transfer data model, but it seems that drb is
not just "transfer".
Even if I ignore the object size thing, still, calling a drbObject's
complex method is an issue.

First thing you should make sure is that you have a clear
understanding of your object model and which of those objects are
remote and which are not. That distinction is important for all
distributed applications regardless of technology used since usually
network communication is the most expensive part of distribution at
runtime. Although I agree to not prematurely optimize I think for a
distributed application the design of the remote interfaces is
important, especially the granularity of method calls and data sent
around.

Kind regards

robert

 

[Magicloud Magiclouds]

First thing you should make sure is that you have a clear
understanding of your object model and which of those objects are
remote and which are not. That distinction is important for all
distributed applications regardless of technology used since usually
network communication is the most expensive part of distribution at
runtime. Although I agree to not prematurely optimize I think for a
distributed application the design of the remote interfaces is
important, especially the granularity of method calls and data sent
around.

Kind regards

robert

Yes, I think so, the design is important, not optimize. I am using some
testing to see how drb works, but something is hard to detect. Could you
tell me your conclusion till now?