Format For Printing...

The Book Of Ruby

by Huw Collingbourne

Thursday 15 May 2008.

Add to del.icio.us

---

The Book Of Ruby
944.8 kb

Forum

• The Book Of Ruby

  29 June 2008, by SoftMind

  Hello,

  Nice book indeed. Thanks.

  I would request you to start a blog/tutorial on Asp.Net MVC with IronRuby. You will find plenty of examples on Ruby On Rails, but a tutorial on starting out with Asp.Net MVC with IronRuby will be gr8 and a pioneer step indeed.

  I have surfed a lot on the net, but still could not get to a tutorial on the above subject. John Lam has of course a mini blog as reference.

  Since IronRuby is the way to go in future and you have always worked hard on this subject. i think you are the right person to start so that other can get a start.

  Since asp.net mvc preview 4 will support Ironruby, with Visual Web developer, it would be nice time for you to keep many things handy right now.

  Thanks

  SoftMind technology.

  Asp.Net MVC with IronRuby

  Reply to this message

  • The Book Of Ruby

    30 June 2008, by Huw Collingbourne

    Thanks for the feedback. This may make a tutorial for the future. Currently we are waiting until IronRuby nears its final release before developing our IronRuby IDE more fully. At that date we shall no doubt be thinking of providing some IronRuby tutorials too ;-)

    best wishes

    Huw

    Reply to this message
• The Book Of Ruby

  2 June 2008

  Hi,

  Thanks for helping us with a great Ruby book like this.

  Since IronRuby would be a more interesting topic, i would like you to focus more on IronRuby than Plain Ruby.

  It would be nice if you can give few examples side by side for IronRuby also. No doubt the syntax remains the same, but calling few codes from C# and implementing with IronRuby would add more mileage.

  James Hardy

  Reply to this message

  • The Book Of Ruby

    2 June 2008, by Huw Collingbourne

    In principle, if IronRuby really is fully compatible with Ruby 1.8x, then this book should be relevant to IronRuby too. In fact, as you say, there will be specific cases where there are special features of IronRuby that need extra explanation. I don’t plan to cover IronRuby in depth in this book but I will be writing articles about IronRuby development heere on the blog. We will be updating our free IronRuby IDE shortly and I’ll start blogging a bit more after that. I’ll consider the possibility of writing a more detailed guide to IronRuby - maybe a bit more like ’The Little Book Of Ruby’ (the Little Book Of IronRuby?) to supplement the information in The Book Of Ruby.

    Many thanks for your interest.

    Huw

    Reply to this message
• The Book Of Ruby

  31 May 2008, by Pit Capitain

  I took a first short look at The Book Of Ruby, chapter 2, but I think I’ll leave it at that. I skimmed the part of accessor methods. Writing "return xxx" as the last line of a method isn’t very Rubyish. Then, it is not correct that when executing "attr_accessor :name" Ruby creates an instance variable called @name. In Ruby, instance variables are created upon the first assignment to them. This is where I stopped. I don’t know how to say it more politely, because I think it’s very generous to write a book and give it to the community for free, but before writing a Book Of Something one should be more acquainted with it.

  Reply to this message

  • The Book Of Ruby

    31 May 2008, by Huw Collingbourne

    If you wish to be absolutely literal, neither the instance variable nor the accessor method is created until a call is made to that method on an instantiated object. If you wish to verify this, take a look in the C Ruby code (eval.c, line 725 and following).

    For completeness, I will discuss Ruby’s symbol table (briefly!) in chapter 11. I tend to think that the degree of literalism which you appear to favour is unlikely to be very useful to most newcomers to Ruby, however. The actual behaviour of Ruby, from the perspective of the programmer, is that both the accessor method(s) and the variable are created when they are used (i.e. no separate declarations needed). To all intents and purposes, therefore, an accessor declaration can be thought of as a shortcut way of creating methods with matching instance variable names.

    As for your objection to ’return’ - I have never understood why some people argue that there is a definitive standard for a ‘Rubyish’ way of coding Ruby. Who decides which things are more Rubyish than others and on what grounds do they arrive at those decisions? My personal prejudice (purely to ensure maintainable code) is to avoid ambiguity whenever possible. I don’t believe that makes it ‘un-Rubyish’.

    I am not sure why you make the assertion that I am unacquainted with Ruby. That is, quite demonstrably, untrue. In the course of programming Ruby itself and also of developing our Ruby debugger and Intellisense systems over many years I can assure you that I have become very well acquainted with Ruby - both the Ruby interpreter and its Ruby and C-code sources. It is this familiarity with Ruby, and my discovery of a number of esoteric ambiguities (which we have had to deal with in our IDE), which has strongly made me favour an explicit coding style in Ruby - hence my preference for explicit returns and bracketed argument lists.

    By all means, don’t read my book. There is no obligation to do so. However, I must say that I do not understand your criticisms, nor do I consider them to be justified.

    Best wishes

    Huw

    Reply to this message
    • The Book Of Ruby

      1 June 2008, by Pit Capitain

      Huw, sorry that I upset you. As I wrote, I didn’t know how to choose better words for what I wanted to say. English is not my native language. Maybe I just had a bad day. I just wanted to mention some things I didn’t expect in a Book Of Ruby.

      Concerning accessor methods and instance variables: look at this example:

       class C
        attr_accessor :v
       end

       c = C.new
       p(c.methods - Object.methods) # => ["v", "v="]
       p(c.instance_variables) # => []

      As you can see, the accessor methods are created, but the instance variable doesn’t exist yet.

       c.v = 123
       p(c.instance_variables) # => ["@v"]

      After assignment, the instance variable finally exists. If you look again at the code in eval.c you mentioned, you can see that the methods are created indeed, but the instance variable isn’t. (BTW: this has nothing to do with symbols.) If newcomers try to access a not yet existing instance variable in their own methods, they’ll get a warning. Not very useful either.

      Concerning style: of course there is no definitive styleguide for Ruby code. But there are things that you will find in the majority of both Ruby’s standard library and in other people’s code, and using an explicit return statement at the end of a method definitely doesn’t belong to them. I didn’t say that those conventions are better or worse than your own coding style, just that they are different.

      But of course this is your book, and it is totally up to you what you make of my comments.

      Reply to this message
      • The Book Of Ruby

        2 June 2008, by Huw Collingbourne

        My approach in this book is principally to describe the behaviour of Ruby rather than its implementation. That said, I do also describe some aspects of implementation, specifically in those areas where the implementation affects the behaviour (normally this is when some kind of ambiguity is inherent in the code but is not obvious if you do not understand certain implementation details of Ruby). I don’t cover metaprogramming until chapter 20, so the creation of methods, classes and variables from symbols and strings is skated over in all the early chapters.

        The precise details of accessors and the ways in which they dynamically create methods and variables is, I think, well beyond my ambitions for chapter 2. It may be worth a more in-depth look in an article here on the site, however. I’ll consider expanding upon this shortly.

        best wishes

        Huw

        Reply to this message
      • The Book Of Ruby

        2 June 2008, by Huw Collingbourne

        By the way, there are a couple of points worth picking n in what you say...

        If newcomers try to access a not yet existing instance variable in their own methods, they’ll get a warning.

        Things are a bit more complicated than that. Consider this...

        class C
  attr_accessor :zzz                       
       
  def abc
     puts @zzz
  end
end

ob = C.new
p ob.zzz       
        #<= nil # no warning
p ob       
        #<= #<C:0x2e30330>  # but no @zzz
ob.abc
        #<= nil # seems to indicate that @zzz is nil
p ob
        #<= #<C:0x27b035c> # still no @zzz (not even @zzz=nil)

        Regarding my preference for explicit returns. There are several entirely pragmatic reasons for this. This would be my preference no matter which language I was writing. One reason is that I like each piece of code to state unambiguously what it is doing. In a fully functional language this is not a problem since the behaviour of functional returns is fundamental to the language. In an object oriented language such as Ruby, however, implicit method returns break encapsulation. e.g.

        class C
  def abc( aVal )
     @myprivatevar = aVal*2
  end
end

ob = C.new
x = ob.abc(100)

        Here, we may assume that the programmer of class C has intended the implementation of method abc to be entirely hidden (‘black box encapsulation’) from the world beyond the class. That is, in procedural terms, it should behave as a procedure rather than as a function. This allows the programmer to reimplement the internal behaviour of the method without any concerns that this may have any side-effects on code that uses class C. However, as we can see, some other programmer in the example above has decided to make use of the return value without the ‘consent’ of the author of class C. Who knows what side-effects that might have if C is reimplemented subsequently?

        At a bare minimum, I use ‘return’ to document those methods whose return values are intended to be accessible to the world beyond my class.

        There are, in fact, exceptions to the rule that Ruby always returns the result of the last expression evaluated. Take a setter accessor as an example:

        def abc=( aVal )
  @myprivatevar = aVal*2
end

        Strictly speaking, if aVal is 100 we should expect this to return 200. In fact, it returns 100. this will remain so even if I add an explicit return:

        def abc=( aVal )
  return @myprivatevar = aVal*2
end

        It still returns 100.

        I have to say that I consider Ruby’s mix of functional with OOP programming to be a bit of a problem area. In particular, my own view is that data-hiding and implementation-hiding should be fundamental features of encapsulation and that Ruby’s method-return values break this fundamental principle. I prefer the Smalltalk tradition whereby methods have explicit returns, otherwise they return the object itself.

        best wishes

        Huw

        Reply to this message
• The Book Of Ruby

  30 May 2008

  There is a typo in your first paragraph - the sentence fragment "each of which is accompanies by read-to-run source code" should read "each of which is accompanied by read-to-run source code".

  Reply to this message

  • The Book Of Ruby

    30 May 2008, by Huw Collingbourne

    Fixed. Thanks.

    Reply to this message
• The Book Of Ruby

  15 May 2008, by Matt Williams

  Not to pick nits, but in your permissions statement, don’t you mean that one cannot modify the programmes "without permission" as opposed to the current "with permission"?

  Reply to this message

  • The Book Of Ruby

    15 May 2008, by Huw Collingbourne

    Oops! Thanks for that. Now fixed.

    best wishes

    Huw

    Reply to this message