To take the discussion in a more serious direction... --- Michael Neale <[email protected]> wrote: > [...] I think freeze was more for dynamic languages like ruby and > groovy [...]
Yes, the "freeze" concept seems more appropriate for dynamically typed languages than for statically typed interface-based languages. Java "supports" a minimal variant of this idea in the Collections class with the "unmodifiable*" methods (and 'public static EMPTY_*' fields), and the well-documented standard UnsupportedOperationException that Iterator.remove() can call. But having a class "advertise" that it implements an interface, and then throwing "does not implement" exceptions in some of the methods of the interface violates the Liskov Substitution Principle (http:// www.c2.com/cgi/wiki?LiskovSubstitutionPrinciple), which is based on the idea that client code should not have to concern itself with the implementation (or partial lack thereof!) of an interface. It's a Java language design issue with no obvious solutions, at this point. This generally suggests using builder patterns in statically typed languages. http://www.c2.com/cgi/wiki?BuilderPattern --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
