The recent rise in popularity and enthusiasm around languages fully equipped of dynamic amazements such as Python and Ruby have made me wish to get started with them trying, where possible, to use them instead of the old static Java. Hallelujah. At last, most of us cried. Since already familiar with Python, I decided to get started with Ruby full of enthusiasm. As a conseguence, as most beginners, I have some doubts especially concerning the adoption of Ruby in large scale projects. I'm aware that, as old Java developer, these doubts might be related to my background, but anyway I'd like to share them.

Reading further on Ruby's object-oriented features, I found out in Programming Ruby that:

Classes are never closed: you can always add methods to an existing class. This applies to the classes you write as well as the standard, built-in classes. All you have to do is open up a class definition for an existing class, and the new contents you specify will be added to whatever's there.

class Folder
  def initialize(name)
    @name = name
    @files = Array.new
  end
  
  def addFile(newFile)
    @files.push(newFile)
  end
  
  def list 
    puts @name+":" 
    for i in 0...@files.length
        puts "--"+@files[i] 
      end
  end
  
end

#base semantics 
aFolder = Folder.new("reports")
aFolder.list
puts "here we're ..."

#...............
#...............
#...............

#...............
#...............
#...............


#override
class Folder
  def list
    puts @name+":" 
    if @files.length == 0
      raise "empty folder!"
    end
      
    for i in 0...@files.length
        puts "--"+@files[i] 
      end
  end
end

#modified semantics 
aFolder = Folder.new("reports")
aFolder.list
puts "never reached!!"

In the previous example the semantics of the method list has been changed on-the-fly. While the first invocation of the method doesn't raise an exception if the array is empty, the second does. That might be an useful feature in some circumstances. On the other hand, I wonder if that could make Ruby classes semantics a bit "context-sensitive" instead of "context-free" as in Java. For example, while in Java when I have to deal with a java.util.ArrayList I'm sure about its semantics (at least, from the moment I took a look at the source code on) no matter if used in a project instead of another (the context), in Ruby if I have to deal with an Array I must be careful if its semantics has been changed somewhere. The more the places I must check, the more the time. Do you believe that could be a problem in large scale projects, where each developer can change the semantics of any class inside any scope? What about the overhead in terms of learning time for each new developer?

In AOP considered harmful, the authors present the obliviousness-property of AOP meaning that "at the source code location describing an affected join point (i.e. a method call, field access, ...) the advice which will be executed is not visible, in contrast to a method call. As a result just looking at the source code line, loop counters or the call stack is not enough to deduce a variable value—a piece of advice might have changed it in-between, invisible for the programmer". Do you believe that the obliviousness-property holds also for Ruby's class definition, meaning that just looking at the source code lines of the first definition of a class isn't enough to fully understand its semantics?

Obviously, a suitable tool could outdo my hard work of manually checking. Such a tool should be able, for instance, to get the actual working definition of each class inside a given scope. Such a kind of tool makes me remind an Eclipse plugin for AOP for getting displayed where advices are/may be applied using a "gutter marker". The markers contain rich information to inform you why there is a (or several) joinpoints on a specific line of source code. In the same way, that reminds me of the objection to AOP of being considered harmful. In the paper by Koppen and Stoerzer, PCDiff: Attacking the Fragile Pointcut Problem, we find the formulation of the so called fragile pointcut problem about AOP, i.e. "a programmer refactoring e.g. a class of the base system is not aware of all the aspects possibly matching joinpoints in this class. Tool support lightens this problem, but in our opinion this does not resolve the problems for evolution of aspects, classes and their dependencies. This also raises another interesting question for companies developing AO software: If failures due to changed pointcut semantics occur, who is responsible? The aspect developer or the base developer? Both answers are not satisfactory ... So in general both programmers have to talk to each other but therefore they have to be aware of potential evolution problems."

In the previous example, things might be a bit worse, as the programmer refactoring the base definition of the class Folder (let's imagine deployed in a different module) turning the name of the method list into listFiles, for example, isn't aware that client source code will run using a further re-definition of the method list (previously, now the only definition of such a method) getting no compile-time error. So, client side invoking the method list you'll get the same results before refactoring as the base class owner performed no refactoring at all. I wonder if refactoring still makes sense in such a context. Still, if failures due to redefined class semantics occur, who is responsible? The base developer or the other developer (if there's only one in the chain)?

class Folder

end

Folder.freeze

class Folder
  def meth      # whatever
  end

  @field = :val # whatever
end

class Folder
  attr_accessor :files
  
  def initialize(name)
    @name = name
    @files = []
  end
  
  def list
    puts @name + ':'
    puts @files.map{|f| '--' + f}
  end
end
 
a = Folder.new('reports')
a.list
 
# ...
 
class Folder
  def list
    puts @name + ':'
    raise 'empty folder!' if @files.empty?
    puts @files.map{|f| '--' + f}
  end
end
 
a = Folder.new('reports')
a.list

class AButton < Button
  def on_click
   ...
  end
end
 
# ...
 
abutton = AButton.new

abutton = Button.new
def abutton.on_click
 ...
end

abutton = Button.new
def abutton.on_click
  alert('First click!')
  def self.on_click
    alert('You already clicked me!')
  end
end