Asp Forum - Why is Ruby dynamic?

Zhao Yi

9/6/2008 1:17:00 AM

People say Ruby is a dynamic language. I don't understand what the
"dynamic"ã??mean here. Does this mean Ruby can dynamic change itself at
run-time?
--
Posted via http://www.ruby-....

10 Answers

James Adam

9/6/2008 4:11:00 PM

On 6 Sep 2008, at 02:16, Zhao Yi wrote:

> People say Ruby is a dynamic language. I don't understand what the
> "dynamic"=E3=80=80mean here. Does this mean Ruby can dynamic change =
itself =20
> at
> run-time?

Essentially, yes. You might consider it sort-of-opposite to a =20
'compiled' language, though that's less strictly true. Ruby objects =20
are completely malleable as your program runs.=

Robert Klemme

9/6/2008 5:26:00 PM

2008/9/6 James Adam <james@lazyatom.com>:
> On 6 Sep 2008, at 02:16, Zhao Yi wrote:
>
>> People say Ruby is a dynamic language. I don't understand what the
>> "dynamic" mean here. Does this mean Ruby can dynamic change itself at
>> run-time?
>
> Essentially, yes. You might consider it sort-of-opposite to a 'compiled'
> language, though that's less strictly true. Ruby objects are completely
> malleable as your program runs.

There are several aspects to Ruby's dynamism: methods and classes can
change at runtime, variables are dynamically typed and generally as
implementing is often faster than in other languages Ruby is very
dynamic (some call it "agile").

Kind regards

robert

--
use.inject do |as, often| as.you_can - without end

Zhao Yi

9/7/2008 2:05:00 AM

Robert Klemme wrote:
> 2008/9/6 James Adam <james@lazyatom.com>:
>> On 6 Sep 2008, at 02:16, Zhao Yi wrote:
>>
>>> People say Ruby is a dynamic language. I don't understand what the
>>> "dynamic"$B!!(Bmean here. Does this mean Ruby can dynamic change itself at
>>> run-time?
>>
>> Essentially, yes. You might consider it sort-of-opposite to a 'compiled'
>> language, though that's less strictly true. Ruby objects are completely
>> malleable as your program runs.
>
> There are several aspects to Ruby's dynamism: methods and classes can
> change at runtime, variables are dynamically typed and generally as
> implementing is often faster than in other languages Ruby is very
> dynamic (some call it "agile").
>
> Kind regards
>
> robert

It is also same for other scripts like perl, python, so they are all
dynamic language?
--
Posted via http://www.ruby-....

Avdi Grimm

9/7/2008 5:04:00 AM

2008/9/6 Zhao Yi <youhaodeyi@gmail.com>:
> It is also same for other scripts like perl, python, so they are all
> dynamic language?

Yup.

--
Avdi

Home: http:...
Developer Blog: http:.../devblog/
Twitter: http://twitte...
Journal: http://avdi.livej...

Bertram Scharpf

9/7/2008 5:40:00 AM

Hi,

Am Sonntag, 07. Sep 2008, 14:04:15 +0900 schrieb Avdi Grimm:
> 2008/9/6 Zhao Yi <youhaodeyi@gmail.com>:
> > It is also same for other scripts like perl, python, so they are all
> > dynamic language?
>
> Yup.

Try to do something like this in Python:

class Time
def german
strftime "%d.%m.%Y, %X"
end
end
class Numeric
def MB
self/1024.0/1024.0
end
end

It's dynamic because it produces dynamic programmers.

Bertram

--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-...

Phlip

9/9/2008 1:21:00 AM

Zhao Yi wrote:
> People say Ruby is a dynamic language. I don't understand what the
> "dynamic"ã??mean here. Does this mean Ruby can dynamic change itself at
> run-time?

It means Ruby can change its objects at runtime. For example:

class Narcissus
def call_once
eval '
class Narcissus
def call_once
raise "nope!"
end
end'
end
end

The first time you call Narcissus.new.call_once, it will not raise. The second
time, it will raise "nope!". Ruby allows class definitions to change on the fly.

--
Phlip

David Masover

9/9/2008 3:11:00 AM

A nitpick, but... string evals considered harmful!

On Monday 08 September 2008 20:19:18 Phlip wrote:
> class Narcissus
> def call_once
> eval '
> class Narcissus
> def call_once
> raise "nope!"
> end
> end'
> end
> end

I'd write this as:

class Narcissus
def call_once
def call_once
raise 'nope!'
end
end
end

But perhaps the more impressive demos are modifying system classes --
re-opening String, for instance -- or eigenclass hacks, or dynamically
generating functions. I always loved define_method. When you know exactly
what kind of things are acceptable:

class PunchCard
%w(fold bend mutilate).each do |action|
define_method action do
raise "Don't #{action} me!"
end
end
end

And when you don't necessarily know, there's method_missing:

class TwoYearOld
def method_missing method, *args
puts "That's MY #{method}!"
end
end

And Ruby makes it very difficult to build a cheat-proof robot game, as you can
always start rewriting the other robot:

class MyRobot
def move
class << other_robot
def move
raise 'Explode!'
end
end
end
end

Of course, it's comforting to know that string evals are there -- having a
working "eval" is a sign of a truly dynamic language. (Probably makes irb
easier to write, too!) But there's very few legitimate uses of it anymore, I
think.

Phlip

9/9/2008 11:03:00 AM

David Masover wrote:

> A nitpick, but... string evals considered harmful!

>> eval '

> I always loved define_method.

I recently tried define_method and it didn't work, so I fell back to eval. (Note
to the newbs: Try things the most progressive way possible, such as a fixed
version of Dave's version of my example, before trying a hack...)

Here's the lines, from inspect_sql:

def self._decorate_explainers(explains) #:nodoc:
def explains.find_statements(regexp)
return AssertEfficientSql._decorate_explainers(select{|explanation|
explanation[:statement] =~ regexp
})
end

(_multiples + _singulars).each do |rollup, explainer|
eval "def explains.#{rollup}; map{|q|q[:#{rollup}]}.flatten.uniq; end"
end

return explains
end

For the eval line, I first tried explains.define_method, and it didn't work.
Instead of researching why, or finding a kindler gentler system, I whipped out
eval and put a bullet thru the problem.

It's the shortest possible eval, anyway!

Also I think you can't say 'def foo; def bar; end; end' - the def is in
method-space, not class-space.

--
Phlip

David A. Black

9/9/2008 11:54:00 AM

Hi --

On Tue, 9 Sep 2008, Phlip wrote:

> David Masover wrote:
>
>> A nitpick, but... string evals considered harmful!
>
>>> eval '
>
>> I always loved define_method.
>
> I recently tried define_method and it didn't work, so I fell back to eval.
> (Note to the newbs: Try things the most progressive way possible, such as a
> fixed version of Dave's version of my example, before trying a hack...)
>
> Here's the lines, from inspect_sql:
>
> def self._decorate_explainers(explains) #:nodoc:
> def explains.find_statements(regexp)
> return AssertEfficientSql._decorate_explainers(select{|explanation|
> explanation[:statement] =~ regexp
> })
> end
>
> (_multiples + _singulars).each do |rollup, explainer|
> eval "def explains.#{rollup}; map{|q|q[:#{rollup}]}.flatten.uniq; end"
> end
>
> return explains
> end
>
> For the eval line, I first tried explains.define_method, and it didn't work.
> Instead of researching why, or finding a kindler gentler system, I whipped
> out eval and put a bullet thru the problem.

define_method is a private instance method of Module, so a typical use
follow something like this path:

c.class_eval { define_method(m) {|x| puts x } }

> It's the shortest possible eval, anyway!
>
> Also I think you can't say 'def foo; def bar; end; end' - the def is in
> method-space, not class-space.

You can nest def's, but the nested one (once the outer one is
executed) becomes an outer one:

class C
def x
def y
puts "Hi from y"
end
end
end

c = C.new
c.x
c.y # Hi from y

d = C.new
d.y # Hi from y

David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.r... for details and updates!

David Masover

9/9/2008 3:34:00 PM

On Tuesday 09 September 2008 05:58:40 Phlip wrote:
> David Masover wrote:
>
> > A nitpick, but... string evals considered harmful!

This is worth bearing. I don't have a problem with eval, only with string
eval. Given that:

> For the eval line, I first tried explains.define_method, and it didn't work.

According to Philip, define_method is a private method, so you can't do that
from outside that object.

Assuming "explains" is a class or a module, you could always go inside the
object:

explains.module_eval do
define_method :foo ...
# More methods?
define_method :bar ...
end

See, I love those, because they can actually take blocks, not just strings.
Since I'd mostly just be passing a variable in through string interpolation,
anyway, it's not only faster, it's safer -- SQL injection is enough of a
problem, we don't need Ruby injection, too!

If it's only a one-off, and you find that eval to be too verbose, there's
always the send hack:

explains.send :define_method, ...

This works mostly because send doesn't check for whether a given method is
actually reachable at that point -- I think you need public_send for that.
Obviously, send is useful for more than just that...

The main legitimate solution I've found is cases like ActiveSupport's
String#constantize -- this is a case where it would take quite a lot more
Ruby to accomplish the same thing as a simple eval. And even here, it's
surrounded by sanity checks, and it's isolated, so that you never have to
know it's there (I didn't, till I looked at the source of constantize out of
curiosity).

And there's always the performance -- I consider evals to be acceptable when
run once, during program start (or at some arbitrary point after that). It's
still code smell, but constantize is an example where the alternative might
be worse. But I'd never call constantize in a Rails view.

comp.lang.ruby

Why is Ruby dynamic?

Zhao Yi

James Adam

Robert Klemme

Zhao Yi

Avdi Grimm

Bertram Scharpf

Phlip

David Masover

Phlip

David A. Black

David Masover

x Login to ForumsZone