Talk Like A Duck: Tag style

Block Your Privates!

Rick DeNatale — Tue, 04 Sep 2007 11:28:00 -0400

I’ve noticed that some rubyists like to use indentation to delineate method visibility.

The first time I noticed this was when Marcel Molina Jr. used it during the charity testing workshop at the Ruby Hoedown.. I just encountered it again in at least one piece of sample code from Rob Orsini’s “Rails Cookbook.”

During the testing workshop, Chad Fowler expressed displeasure with this style, and I’ve got to agree.

Here’s an example of this style:

class Gadget
  def framilize
    razzlitize if options[:secret_ingredient_6X]
  end

  private
    def razzlitize
    end
end

The problem is that the indentation is “artificial”, there really is no nesting of evaluation scope here. The way that Module#private and it’s kin work when they are called without arguments is to set a marker onto Ruby’s eval stack which gets popped when the current evaluation context is exitted. So the effects of the private method remain in effect until either the end of the current context, or one of the other methods like public or protected, whichever comes first. This means that if we extend the above example:

class Gadget
  #...
  private
    def razzlitize
    end

  def dazzlitize
  end
end

The indentation can trick us into thinking that dazzlitize is public when it’s really private.

I’d always found the nature of methods like private without arguments to be a minor annoyance with Ruby syntax. In my humble opinion they should have been able to take a block which delineated their effect. What if we could write:

class Gadget
  #...
  private do
    def razzlitize
    end
  end

  def dazzlitize
  end
end

Well, actually we can write that, but it doesn’t work as expected, since the block is silently ignored, and the method doesn’t even get defined.

So I started doing a little metaprogramming, to fix this. It seemed obvious how to do this. You alias_method Module#private so you can extend it, redefine the method to check for a block and if none is given, call the original method, otherwise evaluate the block in a way which makes any methods defined private. And of course you use test driven design to do this.

I made some progress but ran into some problems:

The obvious way to evaluate the block:
```
class module
  alias :old_private, :private
  def private(*args, &blk)
    if blk_given?
       module_eval do
         old_private
         blk.call
       end
    else
      old_private(*args)
    end
end
```
Doesn’t seem to work. The method isn’t made private. I had to resort to getting a list of the methods before the block, then calling old_private with the difference between the new methods after the block is evaluated, and those before.

The module_eval now looked something like this:
```
module_eval do
  existing = instance_methods(false)
  blk.call
  new_methods = instance_methods(false)-existing
  old_private(new_methods.map {|m| m.to_sym}
```
There are some obvious shortcomings in this code, but at this point, the goal was to do the simplest thing which could work for the test cases at hands, the complications would be dealt with later.
To add insult to injury, calling old_private from within the new definition doesn’t work either, the evaluation context gets marked as described above, but it gets popped off when we exit the context of the new definition. At this point I decided to punt, temporarily at least, and just define a new method Module#with_private which took a block, and leave the existing Module#private alone.
Then I decided that I should test changing the visibility of an existing method, in other words a test case like this:
```
class Test
  protected
  def meth;end
  with_private do
     def meth;end
  end
end
```
Test#meth should end up private, but my simple diff failed to notice the definition, things were starting to get more complicated. It looked like I’d need to hook Module#method_added and probably others. I began to wonder whether it was worth it.

Then I started to ponder the fact that the effect of private/protected/public gets popped when the evaluation context exits. So I said to myself, “Is there a way to take advantage of that?” Well, Virginia, yes there is.

class Gadget
  #...
  class_eval do
    private

    def razzlitize
    end

  end

  def dazzlitize
  end
end

This seems to work as expected, here’s a link to a test case file.

Now I still prefer being able to give a block to Module#private and it’s ilk, and I might still work on that, but in the meantime, class_eval and module_eval seem to provide a way to actually do what I want.

A Perl of Great Price

Rick DeNatale — Wed, 16 Aug 2006 11:03:18 -0400

An old programming adage goes: “You can write Fortran in any language.”

Computer languages, like natural languages, tend to spawn their own cultures and religions. And it’s not unexpected that the groups associated with these have different slants on things.

One of Ruby’s strengths is that it stole from the best. When I look at the language, it feels like Matz took the best features from a variety of languages including Smalltalk, Lisp, and not the least, Perl.

Two great features which Ruby inherited from Perl are integral support for regular expressions, and Perl’s excellent statement modifiers which allow things like:

if test
   statement
end

to be replaced with the more succinct and usually clearer:

statement if test

However, IMHO, overuse of the Perl features in Ruby can make code too Perl-like.

I’ve seen my share of Ruby code which is hard-to read and understand, and a lot of that looks suspiciously like Perl code re-written in Ruby.

A ruby, being a gemstone which is normally cut before being put to use, has facets, unlike a pearl.

The facets of Ruby, the language, let indiduals approach it from different directions. To me, as an old Smalltaker, it tends to look like Smalltalk. I tend to view it with Smalltalk-colored glasses.

I’m sure that, to a programmer deeply steeped in Perl, Ruby looks like Perl with a cleaned-up view of object-oriented features.

Literate Programming

I’ve long been a fan of the goals of literate programming. Source code should be viewed as literature, something which communcates to human readers, and not just fodder for a tool chain which produces something which is executable by a machine.

I read and write Perl on a level similar to how I converse in French. I’m told that I can speak French fairly well, and I can make myself understood. On the other hand I have a hard time understanding spoken French.

Too often, Perl looks to me like a write-only language, an impression which is not uniquely mine.

Some Perl programmers share a common predilection for something which users of another language often called read-only, APL, prided theselves on writing, one-liners. And this has inspired catalogs of Ruby one-liners

I’ve found that a lot of the literature of Perl isn’t very understandable. I’ve found that even Perl code which I’ve written myself is impenetrable when I come back to it weeks, or even days after writing it.

I’m sure that there are Perl programmers who don’t find this to be true, just like my French friends seem to be able to converse without problems, but I continue to only muddle along in both languages.

The key indicator of Perl programs written in Ruby is the use of all those global variables with funny names like $*, $&, $0, etc. Perl programmers love them since they are in Ruby for compatibility with Perl. When I see them, my eyes glaze over, and my mind says ”$&^+_”

I’m not trying to antagonize the Perl programmers among the Ruby community, anymore than I try to antagonize my francophone friends, in fact I’ve got great love for some particular francophones and perlographs.

But I’ll probably never understand them as well as I’d like to.

P.S. Not (Directly) Borrowed From Perl

One feature of Perl is the use of sigils as markers on variable names.

Ruby uses sigils to mark some variables as being globals (there’s that $ again, but the names don’t have to be funny), instance variables, or class variables.

The difference is that Perl uses sigils to distinguish the types of variables, something which is unnecessary in Ruby since everything is an object. Ruby instead uses them to find the variable binding in the case of a reference, or where to put it in the case of an initial definition. A Ruby variable comes into existance the first time it is mentioned in the execution of a Ruby program, and it goes into the global variable “pool”, the current instance, or the current instances class depending on the sigil. No declaration is necessary as compared to Smalltalk, for instance, where instance and class variables are ‘declared’ by telling the class about them, and globals are defined by putting them in the system dictionary. While Perl variables aren’t explicitly declared either, the real motivation for sigils in Perl is to associate a type with a variable.

Perl also makes use of the fact that all variables start with a sigil to automatically interpolate variables into strings. Since ruby variables don’t all start with a sigil, Ruby uses #{} as a marker to interpolate an expression int to a string. Note that if that expression is just a global, class or instance variable (all of which start with a sigil) a simple # will do the job.

So Perl uses sigils more as a way to express type, a static concept, in a dynamically executed language, and Ruby uses them to avoid static declarations, and make variable definition and use dynamic.