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
endThe 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
endThe 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
endWell, 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 endDoesn’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 endTest#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
endThis 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.
Besides being a master werewolf, Marcel Molina Jr. gives great presentations!
In his keynote presentation on the second day of the Ruby Hoedown, Marcel talked about
“What Makes Code Beautiful”,
click on the link for the confreaks video of this session.
The talk started with an exploration of the classical Philosophy of Beauty, from Plato to Descartes.
Marcel summarized this by proposing that beauty lies in the balance between three aspects which,
at times, either strengthen or oppose each other:
- Proportion
- The property that components have the appropriate(relative) size/weight.
- Integrity
- I would summarize this as “fitness of purpose.” Marcel’s anti-example was a
hammer made out of glass. Although it might be beautifully constructed, and a joy to the eye, it
would be unlikely to serve its intended purpose, and thus would fall short on integrity - Clarity
The property of being easily grasped as to meaning and function.
Beauty and Ruby
About 16 minutes into the talk, Marcel started talking about this view of beauty in the context of Ruby code. He gave an example of some really “clever” code to convert strings to an appropriate
instance of a Ruby class, for example “true” would me converted to true, “false” to false, and
strings representing integer or time values to Integers or Times, respectively.
The code in question, implemented a kind of functional language pattern match against the string.
Marcel suggested that he might have been into studying Haskell at the time he wrote this code.
He used a generator to produce an enumerable collection of patterns to try, and did some “nice”
tricks to allow the result of a pattern match to sometimes be solely the value he wanted, and
sometimes to be an array with the value as the second element, to handle the special case where the
desired value was the literal false. If it sounds complicated, it is, I’ve placed the code at
the end of this article.
Some of us in the audience, “smelled” this code right away.
He then critiqued this solution. Although he had originally considered it “beautiful” since it was “elegant” and “sophisticated” he came to smell it too.
A Fresh Design
Here’s how the code ultimately was written:
class CoercibleString < String
def coerce
case self
when 'true': true
when 'false': false
when /^\d+$/: Integer(self)
when datetime_format: Time.parse(self)
else
self
end
end
endOnce this much simpler design is unveiled the original “sophisticated”, and “elegant” design
looks anything but.
Measuring against Proportion, Integrity, and Clarity
- Proportion
- The original is a total failure, it’s much too long compared to the final
code. - Integrity
- Again the original loses on this aspect. The use of the generator, particularly
the early continuation based implementation, causes very slow performance, and leaks memory. Marcel
stated that the simpler version is an order of magnitude faster. - Clarity
- Do I really have to explore this?
Marcel had pointed out when describing the original design that one of it’s “cool features” was
extensibility. Adding a new coercion just required adding another call to try in the Generator.new
block.
In contrast adding a new coercion to the better design just requires adding a when leg to the
case statement.
The Questionable Beauty of Making Subclasses of Core Classes
While I loved the talk and agree with 99 and 44/100%, I’m just a bit troubled by the introduction
of the CoercibleString class. I think that it falls down on proportion at least.
It seems to me that there’s some missing code here. How do you actually coerce a string.
This seems to strongly imply a usage like this:
class PayloadProcessor
def process
# code which extracts a string to be coerced
#coerce the string referenced by the variable value_str
value = CoercibleString.new(value_str).coerce
#further processing
end
endAn alternative, and it seems to me to be a better one, although I’m convinceable otherwise, would
be to just make that method part of the class requiring the conversion, either directly, or through a
module:
class PayloadProcessor
def process
# code which extracts a string to be coerced
#coerce the string referenced by the variable value_str
value = coerce(value_str)
#further processing
end
def coerce(str)
case str
when 'true': true
when 'false': false
when /^\d+$/: Integer(str)
when datetime_format: Time.parse(str)
else
str
end
end
endNow some might argue that the ‘functional’ looking coerce method which takes the string
as an argument rather than the receiver seems somehow less ‘object oriented’, but I find this
unconvincing.
If CoercibleString is a class we need code to create it from a string, something like:
class CoercibleString < String
# Create a new coercible string
# Note that since the actual value of
# Ruby strings are not held by an instance variable
# we need to alter the internal representation
def initialize(source_str)
self << source_str
end
endI had a brief conversation with Marcel about whether or not subclassing string really seemed
appropriate, but it lasted all of about a minute. There’s a bit of supposition here on my
part, so apologies to Marcel if I misunderstood the exchange. He indicated that he would probably
advocate
defining a method called CoercibleString, in parallel with Kernel#Integer and its ilk.
module Kernel
def CoercibleString(str)
CoercibleString.new(str)
end
endBut this syntactic sugar, just seems to be tilting the balance towards a less proportional design.
Conclusion
Building new classes is often a good idea, but not always. I’m not totally convinced that
coerce(str) is more beautiful than CoercibleString.new(str).coerce, or CoercibleString(str).coerce,
but my sense of esthetics tilts me that way.
Comments?
A “Smelly” Way to Coerce Strings
Here’s Marcel’s original code:
class CoercibleString < String
attr_accessor generator
def coerce
attempt = nil
break unless {attempt = coercions.next).nil? while coercions.next?
attempt.nil? ? self : attempt
end
private
def coercions
Generator.new do | self.generator |
try { self == 'true' }
try { [self == 'false', false ] }
try { Integer(self) }
try { Date.parse(self) }
end
end
def try
attempt, desired = yield
generator.yield(desired.nil? ? attempt : desired) if attempt
rescue ArgumentError
generator.yield nil
end
endIf you subscribe to my feed, you might have noticed a mysterious "Testing Testing" article today.
I was trying a desktop blogging client called BloGTK, and it doesn't appear to honor the checkbox in the UI which is suppose to prevent actually posting an article.
Good article about a basic principle of UI goodness by Jef Raskin’s son Aza.
Have you ever had that sinking feeling when you realize—just a split second too late—that you shouldn’t have clicked “Okay” in the “Are you sure you want to quit?” dialog?
My RSS reader uncovered a thought provoking paper by Chris Smith entitled “What To Know Before Debating Type Systems”. It clears up a lot of the confusion around the differences between static and dynamic type systems.
Much of the debate comes from people with limited exposure to both static and dynamic typing. He observes that:
- Many programmers have used very poor statically typed languages.
- Many programmers have used dynamically typed languages very poorly.
<blockquote class = "pullquote">
Many programmers have used very poor statically typed languages.
Many programmers have used dynamically typed languages very poorly.
He then points out that although there is a good deal of overlap in the problems which can be solved by the two approaches, they are fundamentally different techniques. According to the paper:
A static type system is a mechanism by which a compiler examines source code and assigns labels (called “types”) to pieces of the syntax, and then uses them to infer something about the program’s behavior. A dynamic type system is a mechanism by which a compiler generates code to keep track of the sort of data (called its “type”) used by the program. The use of the same word “type” in each of these two systems is, of course, not entirely coincidental; yet it is best understood as having a sort of historical or generalized significance. Great confusion results from trying to find a world view in which “type” really means the same thing in both systems. It doesn’t.
Most of the popular languages with static type systems use static types to mechanically prove that a program is type-safe. Programs for which this can be proven are accepted, and others are rejected. The paper shows that for any such type-system there will be correct programs which cannot be proven correct and will be rejected.
Languages with dynamic type systems allow execution of programs without prior proof of ‘innocence.’ However, the presence of meta-information at run-time allows for fast-failure and better context for correction when errors do occur.
The type systems of most popular statically typed languages are rather limited in the properties which can be proven. Not all program bugs can be statically determined. Seemingly easy checks such as arrray index checking are actually quite difficult to express statically, most languages don’t check this statically. As Smith says, “this is an unusually hard problem to solve without making the languages that solve it unusable, but it’s a popular one to work on” as a research topic. Reading this paper has motivated me to learn more about Haskell to explore how easy or hard it is to push the notions of what can be statically checked.
It occurs to me that a language like C++ has a Napoleonic-code where you are ‘guilty until proven innocent’, but once you’ve gotten through the trial, you are free to go where you want and do what you want to do. However this means that if you are guilty of something which the type-system doesn’t discover, like an array bounds violation, your malfeasance might be undetected for some time, and then require sophisticated forensics to debug. In Ruby or Smalltalk, you are ‘innocent until proven guilty,’ but your actions are under a higher level of surveillance by the system.
Smith wraps up by re-framing the static vs. dynamic typing debate:
Static type systems prove properties of code, but it almost appears that Rice’s Theorem means we can’t prove anything of interest with a computer. If true, that would be an ironclad argument against static typing systems. Of course, it’s not true. However, it is very nearly true. What Rice’s Theorem says is that we can’t determine anything. (Often the word “decide” is used; they mean the same thing here.) It didn’t say we can’t prove anything. It’s an important distinction!
What this distinction means is that a static type system is a conservative estimate. If it accepts a program, then we know the program has the properties proven by that type checker. If it fails… then we don’t know anything. Possibly the program doesn’t have that property, or possibly the type checker just doesn’t know how to prove. Furthermore, there is an ironclad mathematical proof that a type checker of any interest at all is always conservative. Building a type checker that doesn’t reject any correct programs isn’t a challenger that may be solved some day; it’s impossible.
That, then, is the trade-off. We get assurance that the program is correct (in the properties checked by this type checker), but in turn we must reject some interesting programs. To continue the pattern, this is the diametric opposite of testing. With testing, we are assured that we’ll never fail a correct program. The trade-off is that for any program with an infinite number of possible inputs (in other words, any interesting program), a test suite may still accept programs that are not correct – even in just those properties that are tested.
He then poses eight questions to ponder when considering where and how to use static or dynamic typing in our programming tasks:
- For what interesting properties of programs can we build static type systems?
- How close can we bring those type systems to the unattainable ideal of never rejecting a correct program?
- How easy can it be made to program in a language with such a static type system?
- What is the cost associated with accidentally rejecting a correct computer program?
- For what interesting properties of programs can we build test suites via dynamic typing?
- How close can we bring those test suites to the unattainable ideal of never accepting a broken program?
- How easy can it be made to write and execute test suites for programs?
- What is the cost associated with accidentally accepting an incorrect computer program?
Recently on gluttonous, Kevin Clark announced that
Powerset is going to launch their front-end on Ruby. It seems that they were already pre-disposed to a major ruby comitment having built a sizable Ruby talent pool for their internal applications.
Prior to making the final decision to go all out with ruby for their front-end launch, the did some due diligence which included investigating the facts behind the recent furore caused by an interview with one of Twitter’s developers.
So they went to
Twitter’s lead developer, Blaine Cook to get the straight dope.
Quoting Kevin:
The simple fact is that Ruby wasn’t the source of Twitter’s woes. As it often happens with rapidly growing sites, they ran into architectural problems. Some design decisions don’t hurt until they reach a massive scale and at that point you have to rethink your approach. In an email he writes:
For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January
That last sounds quite true and corresponds to my experiences in the past with Smalltalk. I used to tell IBM customers that almost all performance comes not from the language but from application design, and that using a dynamic language which allowed the application to be developed in what’s now called an agile development process allows major performance gains through refining, refactoring, and retuning the system as both business and performance requirements get uncovered/discovered.
That’s as least as true of Ruby as it was of Smalltalk 15-20 years ago.
<iframe align = “right”, src=“http://rcm.amazon.com/e/cm?t=denhaven2com-20&o=1&p=8&l=as1&asins=0201184621&fc1=000000&IS2=1<1=_blank&lc1==E50707&bc1=000000&bg1=FFFFFF&f=ifr&npa=1” style=“width:120px;height:240px;” scrolling=“no” marginwidth=“0” marginheight=“0” frameborder="0">
Most programmers these days are familiar with, or at least aware of the now classic
“Gang of Four” book Design Patterns: Elements of Reusable Object-Oriented Software
One of the recurring arguments about design patterns is how they relate to individual programming languages. The “Gang of Four,” Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, were by majority, proponents of strongly typed languages. Ralph was the sole representative of Smalltalk and the rest of the dynamic object oriented languages. As a result, The GOF book had and has more resonance with the C++ community and it’s successors. Although there
are some Smalltalk examples in the book, many of the patterns express things which are easier, and in some cases
unnecessary to express in a dynamically typed language. I find this a bit ironic, since the whole patterns movement
seems to have started when Ward Cunningham and Kent Beck, two of the best known Smalltalkers, discovered the work of architect
Christopher Alexander and thought that his approach to building and municipal design could be translated to the
design of software.
As I was browsing today, I was reminded that there is another “Design Patterns” book,
“The Design Patterns Smalltalk Companion” by Sherman Alpert, Bobby Woolf, and Kyle Brown.
Which might be of interest to not just Smalltalkers
but also Rubyists, since it approaches the subject from they dynamic language point of view. It’s not easy to find, but Amazon has a few copies in stock.
Sherm was one of the researchers in the IBM User Interface Institute
which was housed in the same building where
John Vlissides and Richard Helm of the “GOF” worked,
the IBM Watson Research center in
Yorktown Heights, NY. I spent quite a bit of time with Sherman and the rest of the UI institute team under John T.
Richards back in the late-1980s to early 1990s.
Bobby and Kyle were OO consultants, who I also knew through Knowledge Systems Corp.
You never know what you might learn from the old Smalltalkers.