Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Discussion 1 - Dasha K
Source: Conference on Object Oriented Programming Systems Languages and Applications
Year of Publication: 2004
- Encapsulation: The title of Nathanael Scharli, Andrew P. Black, and Stephane Ducasse's paper clearly indicates that the discussion at hand involves encapsulation. From the very first line of the text, the authors introduce their main point - the lack of (or in some languages, such as Python, extremely limited) support of encapsulation in dynamically-typed languages. They claim that traditionally the concept has been based on static type systems which not surprisingly caused languages such as Smalltalk, Self, Python, and Ruby to have virtually no encapsulation at all. They write that while support for encapsulation (which they later discuss in terms of types such as module, object, and a more all-encompassing global type) is already fairly strong in statically-typed languages (Java, C++, C#) and proposals are successfully introduced to even further the effect, their dynamically-typed "siblings" are in need of a substitute or an alternate solution.
- Lessons from the Past: The authors of the paper have a proposal of their own consisting of what they call object encapsulation (as opposed to module encapsulation which pretty much consists of minimizing interdependencies between separate modules as well as the use of external interface orchestrating the communication between the module and its clients). However, before the paper moves on to the actual proposal, the authors pause to discuss the numerous encapsulation models of the past. The paper then lists a number of possible reasons why previously proposed encapsulation models for dynamically-typed languages didn't succeed. On one hand, it lists the model proposed by Self developers that was included in an experimental release of the language but was later found to be too complex to be useful. On another hand, the paper discusses encapsulation models similar to Smalltalk extension MUST which simply interfered with the dynamic character of the language "requiring the programmer to make quite static encapsulating decisions both when declaring methods and when sending messages". Finally, the paper reminds us that the dynamic languages were initially promoted and started out mainly as experimental projects and that even further down the road the same image made encapsulation seem unnecessary.
- Custom Design: The need for encapsulation is evident. Regardless of how the data is declared and allocated (statically v dynamically), it needs to be protected and processed with care. The entire first half of the paper was dedicated to the discussion of why encapsulation is so important, why even though the models haven't been successful in the past a well thought out and planned model is needed; and, finally, the paper listed the key ideas of class and object encapsulation mechanisms. Instead of models that imitated static encapsulation and at times even interfered with the dynamic character of the language(s), the object-oriented encapsulation model proposed in this paper provides protection similar to that of the static encapsulation models but achieved dynamically.
- In relation to J. David Shirley's discussion on the same topic of encapsulation: I agree with the above poster on a couple of points. Java and some other languages do seem to provide a bit more flexibility and fine-tuning for the developer when compared to dynamic languages with their "strict" rules. However, as in the example with the public-private method scenario in Java which can give the same end result in Smalltalk, it's all about trade offs and the different intended usage.
Links to this Page