Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution

From APIDesign

Revision as of 00:52, 29 September 2008

This is where Java's strong typing steps in your way. What about languages which do not have such strong typing? For example Ruby's duck-typing seems to sidestep this problem in a simple way - because there is no need for "abstract" in Ruby, this issue obviously does not exist there. The price you pay for this flexibility in Ruby in this case is that you should use introspection (xx.respond_to? :getHTMLTitle) to find out whether the object xx actually provides the method getHTMLTitle or not. However, if you have not used Ruby before, beware - Java programmers usually do hate it, just because it is not strong typed - they refuse the duck-typing just because it seems perverse to them. However, it is not so perverse once you get used to it. ;-)

-- an Anonymous Coward on 20:11, 21 September 2008

OK, let's accept the view that duck-typing really helps to solve the problem of enhancing an existing interface with String getHTMLTitle() method. What can users of such method do? Well, they need to check whether an object implements the method or not and either send the message or do something else:

// written in a pseudo language with "respond_to" operator:
title = null;
if (xx.respond_to? :getHTMLTitle) {
  title = xx.getHTMLTitle();
} else {
  title = "<b>" + xx.getDisplayName() + "</b>";
}

this is possible. However it does not contribute to the simplicity of API usage. The if statements are only likely to grow, they are spread all around the code base and after few releases the maintenance becomes a nightmare. Btw. in Chapter 6, Code Against Interfaces, Not Implementations, I show that similar nightmare can happen in Java:

public abstract class View {
  public abstract String getDisplayName();
}
public abstract class ViewVersion2 extends View {
  public abstract String getHTMLTitle();
}
 
title = null;
if (xx instanceof ViewVersion2) {
  title = ((ViewVersion2)xx).getHTMLTitle();
} else {
  title = "<b>" + xx.getDisplayName() + "</b>";
}

As can be seen, this style produced almost as bad code as the Ruby example above. The truth is that when evolving an interface, you most likely want to provide default implementation of getHTMLTitle to all existing and already written classes. The simplest trick to achieve that in Java is:

public abstract View/*version 2.0*/ {
  public abstract String getDisplayName();
  public String getHTMLTitle() {
    return "<b>" + getDisplayName() + "</b>";
  }
}

Only then you simplify life of your API clients. I'd bet that similar code can be rewritten to Ruby, without use of duck-typing. As such, I'd like to conclude that duck-typing does not simplify API evolution, at least not in this particular case. Looks like Languages Ready for Evolution are unlikely to benefit from duck-typing.

--JaroslavTulach 15:48, 22 September 2008 (UTC)

If you would like to write a code which could use both the old version of the class (which does not provide some method) and the new version of the class (which provides that method), you would obviously end up with the code similar to "if (using_new_class) { use_provided_method } else { do_it_yourself }", which is not nice.

I think that the benefit of Ruby in this case is that you can seamlessly use the new version of the class with some legacy code which uses this class (with absolutelly no change needed for that legacy code). Of course only if the new version of the class would not break whatever the old version of the class has provided already. Adding new functionality is allowed.

If used with a proper versioning system (based for example on something like RubyGems' "gem 'library_name', '>= 3.1', '< 4.0'" attached to the client code), this could result in a quite nice approach to API evolution, couldn't it? The infrastructure would ensure that you would have a class with proper version available, so you could avoid writing the ugly code testing for availability of the methods you would like to use. On the other hand you would be obligated to increase the major version number of the library every time you introduce any backward-incompatible change to it. It would be nice to have such version numbers generated automatically, but because it is impossible to do it 100% correctly (think about semantic changes, time or memory effectiveness, etc.), letting the author of the library to assign the version numbers seems like a reasonable approach.