Why is Ruby dynamic?

ruby-talk
1

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-forum.com/.

2

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.

···

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?

3

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

4

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

···

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.

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

5

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

   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.

···

On Monday 08 September 2008 20:19:18 Phlip wrote:

6

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"e$B!!e(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-forum.com/\.

7

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

8

Yup.

···

2008/9/6 Zhao Yi <youhaodeyi@gmail.com>:

It is also same for other scripts like perl, python, so they are all
dynamic language?

--
Avdi

Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com

9

Hi --

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

···

On Tue, 9 Sep 2008, Phlip wrote:

--
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.rubypal.com for details and updates!

10

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.

···

On Tuesday 09 September 2008 05:58:40 Phlip wrote:

11

Hi,

> 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

···

Am Sonntag, 07. Sep 2008, 14:04:15 +0900 schrieb Avdi Grimm:

2008/9/6 Zhao Yi <youhaodeyi@gmail.com>:

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

12

Hi,

> > 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

Python is "dynamic" compared to, say, C or Java. People tend to want to
classify languages in a black/white manner, putting some languages on one
side of a dividing line between "dynamic" and "static", and other
languages on the other side. The way most people view these things,
Perl, Python, and Ruby are all "dynamic".

That doesn't mean they're all *equally* dynamic, of course -- as you
point out. The fact they aren't all equally dynamic doesn't mean Python
isn't "dynamic" as well.

It's dynamic because it produces dynamic programmers.

That's certainly one way to look at it -- and it does indeed seem to at
least facilitate, if not produce, "dynamic programmers".

···

On Sun, Sep 07, 2008 at 02:39:37PM +0900, Bertram Scharpf wrote:

Am Sonntag, 07. Sep 2008, 14:04:15 +0900 schrieb Avdi Grimm:
> 2008/9/6 Zhao Yi <youhaodeyi@gmail.com>:

--
Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ]
Olin Shivers: "I object to doing things that computers can do."