Today's reading has been "On Understanding Data Abstraction, Revisited" by William R. Cook. It has really been an eye-opener on the differences between abstract data types and objects, and it have helped me understand the implication of the different approaches taken by different programming languages.
Highly recommended.
Showing posts with label types. Show all posts
Showing posts with label types. Show all posts
Sunday, December 6, 2009
Sunday, March 15, 2009
'This' type and Covariant builders
When designing your own APIs, either by using interfaces or class hierarchies, you usually find the need to reference the type of the actual implementacion of the interface or class you are writing. This is an actual problem, and there's even a proposal in Project Coin (small language changes for Java 7) to deal with it.
One of this cases, and the one the rest of this post is focused on, is using the 'This' type as the return type of some methods. This is particularly useful for method chaining in fluent interfaces.
Up until Java 5, and the introduction of covariant return types, it was impossible to deal with this issue, which led to frequent casting. But even with Java 5+, the solution is based in manually overriding every method in the subclass (or subinterface) changing the return type to the desired subtype, calling super and returning this.
So, I have checked-in a partial solution to this issue. The type signature of the Type class This<T extends This<T>> (equivalent to that of the Enum class) allows the implementation type to be referenced inside the class, and its value obtained by calling thisValue. But not only the final implementation type, but also some siblings in the hierarchy (as showed in the tests), as the Java type system cannot guarantee this.
That's the reason for the validation in the constructor of This, the reason it is an abstract class instead of an interface, and one of the many reasons it is only a partial soluction.
One application of the This type is for builders (see the builder pattern and item 2 in Effective Java 2nd Ed.). If your builder is part of a hierarchy you are faced with the problem described in this post, so I've also included a base class for them, the covariant builder.
One of this cases, and the one the rest of this post is focused on, is using the 'This' type as the return type of some methods. This is particularly useful for method chaining in fluent interfaces.
Up until Java 5, and the introduction of covariant return types, it was impossible to deal with this issue, which led to frequent casting. But even with Java 5+, the solution is based in manually overriding every method in the subclass (or subinterface) changing the return type to the desired subtype, calling super and returning this.
So, I have checked-in a partial solution to this issue. The type signature of the Type class This<T extends This<T>> (equivalent to that of the Enum class) allows the implementation type to be referenced inside the class, and its value obtained by calling thisValue. But not only the final implementation type, but also some siblings in the hierarchy (as showed in the tests), as the Java type system cannot guarantee this.
That's the reason for the validation in the constructor of This, the reason it is an abstract class instead of an interface, and one of the many reasons it is only a partial soluction.
One application of the This type is for builders (see the builder pattern and item 2 in Effective Java 2nd Ed.). If your builder is part of a hierarchy you are faced with the problem described in this post, so I've also included a base class for them, the covariant builder.
Sunday, September 7, 2008
Types and Programming Languages
Putting my money where my mouth is, in my last order to amazon (dollar is still cheap) I got Pierce's Types and Programming Languages, after having it in my wish list for a long time.
I expect it to be a long read, as it is pretty long and dense. In any case, even though it is quite academical, I'm sure it'll be eye-opening. Stay tuned.
I expect it to be a long read, as it is pretty long and dense. In any case, even though it is quite academical, I'm sure it'll be eye-opening. Stay tuned.
Friday, May 16, 2008
On Types and Programming Languages
Programming languages and type systems are two fascinating subjects inside computer science, and there are plenty of sites devoted to them. They are great fields of research for academics (and the industry) and source of endless debate in the open source world and the blogosphere.
This week, static vs dynamic typing has been brought again to the front page by this (lengthy as usual) post by Steve Yegge. If you go through the transcript of this pretty interesting presentation you'll see that in the end, he really focuses on dynamic just-in-time compilation techniques, which are also available for statically typed languages (provided they are run through some kind of vm, such as the hotspot java virtual machine). Anyway, after (or in reaction to) this post a great amount of content in the subject has flourished.
As a debate in itself, it is really interesting because it's a good way to get introduced to new advances in both camps (and to discover the past, there many things that sound new but were invented decades ago). And in my opinion, it's endless in nature, as the only absolute truth may be that there is no language (nor type system) that fits best in all situations.
So in the end, in many cases is just a matter of personal preference. And even though I really get the value (and in many cases even the need) of dynamically-typed languages I have some personal bias towards static typing (I'm nearer to Cédric's position).
Ironically, I've found myself limited many times by the type system of the programming language at hand (mostly Java) but that has only increased my interest in learning the possibilities provided by languages with more expressive type systems (ML family, Haskell, Scala...).
Subscribe to:
Posts (Atom)