Lambda the Ultimate The Programming Languages Weblog - join today!

Home

FAQ

Feedback

Departments

Discussions

(new topic)

Language Evaluation

PL Courses

Research Papers

Design Docs

Quotations

Genealogical Diagrams

Members Join Now Login

oop

Selective Open Recursion: A Solution to the Fragile Base Class Problem

Jonathan Aldrich. Selective Open Recursion: A Solution to the Fragile Base Class Problem. Submitted for publication. We propose to change the semantics of object-oriented dis-patch, such that all calls to "open" methods are dispatched dynamically as usual,but calls to "non-open" methods are dispatched statically if called on the current object this, but dynamically if called on any other object. By specifying a method as open,a developer is promising that future versions of the class will make internal calls to that method in exactly the same way as the current implementation. Because internal calls to non-open methods are dispatched statically, developers can change the way these methods are called without affecting subclasses. It may be worth noting that in Ada calls aren't automatically dispatching, and the language provides a mechanism quite similar to the one discussed here. Posted to OOP by Ehud Lamm on 5/13/04; 5:59:24 AM Discuss (5 responses)

Object-Oriented Programming Enhancements in Ada200Y

S Tucker Taft. Ada User Journal. This article provides an overview of four proposed amendments to the Ada standard for possible inclusion in the revision planned for late 2005 or early 2006. Together, these four amendments can be seen as "finishing" the job of integrating object-oriented programming features into Ada. A high level discussion of some of the changes being considered for the next revision of the Ada language. More in depth discussions can be found on the ARG (Ada Rapporteur Group) web site (the AIs and ARG Minutes make for interesting reading if you are into Ada). Posted to OOP by Ehud Lamm on 5/7/04; 6:16:47 AM Discuss (1 response)

Alan Kay to receive Turing Award

Congratulations! I don't begrudge him the award or anything, but it seems the award committee is a bit moonstruck when it comes to OOP. 2001 wasn't that long ago. Isn't it a time for a Haskellist to win? Be that as it may, as far as charcter and personality go, not to mention life long dedication, commitment, and accomplishment there are few who could top Kay. Having read Kay and about Kay, I have a feeling that hearing his Turing Award lecture is going to make quite a few people squeak, not all of them with joy... Posted to OOP by Ehud Lamm on 4/21/04; 2:41:33 AM Discuss (5 responses)

Apocalypse 12: Perl 6 OO

As usual, Keith is the first to alert us of a new Apocalypse from Larry Wall. The design Larry explains in this document is rather interesting, having at its core a somewhat Meta Programming based approach. I am not sure I'd want to program in such a language, but from a language hacking point of view the language features discussed look quite exciting... Posted to OOP by Ehud Lamm on 4/17/04; 11:22:37 AM Discuss

Java to gain multitasking improvements

(via JavaLobby) J2SE 1.6, which is scheduled for a beta release this fall with general availability eyed for 2005, is slated to feature an "isolates" function to boost application-sharing in the JVM, according to Murali Kaundinya, senior Java architect for Sun Software Services. The isolates capability would enable isolated entities to perform localized computation without requiring a second JVM, thus enabling multitasking within the JVM, according to Kaundinya. Now that there going to allow multiple independent programs to run under a single JVM instance, I guess they're going to have to come up with some protocol for the two programs to talk to each other in a loosely couple protocol (events, semaphores, etc...). Unless they go that route, I'm not sure what the feature buys, other than rubber stamping a JVM design that can handle more than one program instance (something which an optimizing JVM environment could probably do under the hood, if the implementers were so inclined). But then, I haven't seen the specs on invocation. Posted to OOP by Chris Rathman on 4/8/04; 10:12:43 PM Discuss (6 responses)

New Language Features in C# 2.0, Part 1
Some examples of the new C# features of anonymous functions, iterators, and partial classes. These additions have been discussed several times on LtU. (But heck, it's a slow news day, especially with our editor-in-chief away on a densely populated island). Posted to OOP by Chris Rathman on 4/7/04; 11:42:11 AM Discuss

Prothon

A protoype based variant of Python. Prothon is a fresh new language that gets rid of classes altogether in the same way that Self does and regains the original practical and fun sensibility of Python. This major improvement plus many minor ones make for a clean new revolutionary break in language development. Prothon is quite simple and yet offers the power of Python and Self. From /. Posted to OOP by andrew cooke on 3/26/04; 11:24:47 AM Discuss (5 responses)

MIT Theta Language and Thor Distributed OO Database

Theta is a sequential, strongly-typed, object-oriented language. It provides separate mechanisms for type hierarchy, inheritance, and parametric polymorphism. It also provides separate mechanisms for specifications, which define the interfaces of new abstractions, and code that implements the new abstractions, and it allows multiple implementations of types and routines. It has a module mechanism that encapsulates the details of type and routine implementations, while allowing related implementations to share implementation-specific information. Theta is largely derived from CLU, but has also been influenced by Trellis/Owl, Modula-3, C++, and Emerald. One more for the single-letter languages list. A product of MIT's Programming Methodology Group. Developed for this group's Thor system: Thor is a large-scale distributed, object-oriented database system that provides reliable and highly available persistent storage for objects.... Thor allows application programmers to use their preferred programming language and even to develop applications using a variety of programming languages; the components in the different languages will be able to inter-operate by sharing objects in Thor. The objects in Thor are specified and implemented in Theta, a new programming language developed by the Programming Methodology Group. Posted to OOP by Mark Evans on 2/27/04; 11:50:24 AM Discuss (3 responses)

Micro Autonomous Underwater Vehicles and Smalltalk

Jon Hylands' MicroSeeker is powered by Smalltalk. Quote: There are two distinct systems in MicroSeeker. The first is the low-level, real-time data acquisition and control system. This is run by a network of PIC microcontrollers. They originally ran PIC/Smalltalk, a language I wrote, but I decided to concentrate more on the AUV end of things and less on supporting a new compiler, so I use CCS C now. The second system is the high-level autonomous control system. That level will be running on a single-board Axis computer running Linux, and it will be written in Squeak. Posted to OOP by Patrick Logan on 1/21/04; 4:28:55 PM Discuss (10 responses)

The Behavior of Behavior
Dave N. (IBM) Smith's tutorial on Behavior in Smalltalk. (pdf) Explains why #new is an instance method of class Behavior and other things that make Smalltalk so simple and powerful, yet so mysterious when you first look into how it works under the hood. Posted to OOP by Patrick Logan on 1/8/04; 12:21:15 PM Discuss (5 responses)

A Self-Study Course in Squeak

You want to learn Squeak. You have downloaded and installed it. You've poked around the image. You've bought and read one of the many Smalltalk books. You've browsed the Swiki pages and printed off and read some of the tutorials. You lurk at the Yahoo Squeak Maillist Archive. And yet you still don't feel like you know what it's all about. You'd like to start becoming a "contributing member" (been listening to too much PBS;) but aren't sure you could even comment on bugs. If you have an application in mind, you don't know where to start working on it. It all feels to overwelming. Maybe you'll try again after the new year.... The self-study Squeak tutorial, over on the Squeak Swiki, is for people in this situation. It doesn't contain much yet, but it has the potential to evolve into a useful resource. Some of you may want to follow the course, other may feel inclined to contribute. Posted to OOP by Ehud Lamm on 12/1/03; 5:43:53 AM Discuss

Dynamic Properties

From the dotnet undocumented blog... Avalon has this concept of dependency properties (used to be called as dynamic properties), which I think is cool. Instead of keeping the backing store of properties inside an object (derived from DependencyObject), Avalon stores in the object a reference to list of non-default property values. And from "Lisp 1 to 1.5"... The idea of providing each atom with a list of properties was present in the first assembly language implementation... Several functions dealing with property lists were also made available for application programs which made heavy use of them. And finally, Greenspun's Tenth Rule... Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. Does anyone else find irony in simultaneously introducing statically checked generics as well as dynamically checked properties into a language? Posted to OOP by Patrick Logan on 11/30/03; 8:02:38 PM Discuss (30 responses)

Coplien: Teaching OO

I found this via Python Daily-URL (which now has an RSS feed), and since I've been thinking recently about defning and teaching OO (I have a meeting about this Wednesday), I had to take a look. Not a lot of new stuff in here, but I am pleased to see that in most respects Coplien's approach is similar to the one used in the course I run. ADTs and abstraction first, only than inheritance and polymorphism. Put the emphasis on interfaces early, and keep hammering it in. Posted to OOP by Ehud Lamm on 11/17/03; 11:08:16 AM Discuss (5 responses)

A Survey of Object-Oriented Concepts

Nierstrasz Oscar, 1989. A Survey of Object Oriented Concepts. Chapter in object oriented concepts, databases and applications. Won Kim, Frederick H. Lochovsky (Eds.) ACM Press. Object-oriented languages and systems are a developing technology. There can be no agreement on the set of features and mechanisms that belong in an object-oriented language since the paradigm is far too general to be tied down. (What features belong in a declarative language?) The idea of using objects to model software is a natural one that will inevitably appear and reappear in various forms; we can expect to see new ideas in object-oriented systems for many years to come. This paper is from 1989. Do you think it would have looked significantly different had it been written today? Posted to OOP by Ehud Lamm on 11/16/03; 4:35:46 AM Discuss (5 responses)

Coalgebraic Reasoning about Classes in Object-Oriented Languages

Bart Jacobs, Coalgebraic Reasoning about Classes in Object-Oriented Languages. Electr. Notes in Comp. Sci. 11, 1998. Special issue on the workshop Coalgebraic Methods in Computer Science (CMCS 1998) A very short and accessible introduction. Figure 2 that shows an example of the late binding semantics of Java, is a good way to make sure you understand what OOP is about (and for use on your friends and coworkers). The best sentence in this paper, as far as I am concerned, is this one: Discussing these mechanisms [inheritance and aggregation] within the LOOP tool would lead too far, but they form of course essential ingredients of the object-oriented pardaigm -- whatever that may be. Posted to OOP by Ehud Lamm on 11/10/03; 2:01:16 AM Discuss (8 responses)

Groovy Language

Groovy is a powerful new dynamic language for the JVM combining lots of great features from languages like Python, Ruby and Smalltalk and making them available to the Java developers using a Java-like syntax. James Strachan has seemingly orphaned his Jelly language for a new-and-improved Java called Groovy. Whatever its merits or demerits, I find this effort an interesting software ecosystem case study. The Groovy team already knows about Nice, Pizza, and Jython (though probably not Flow Java, MultiJava, or Jiazzi), yet feels an urge to roll a new language. Java is spawning a large litter. Posted to OOP by Mark Evans on 10/24/03; 11:43:30 PM Discuss (2 responses)

Dan Friedman: Object Oriented Style

(slides) (code) The final version of the paper, as it was submitted to ILC2003 (International Lisp Conference, NY) and presented there, is quite different from the previous effort discussed here previously. In particular, all macros are different. All examples are different. The macros are a real tour de force. The only thing in common between this and the previous version is the overall idea. Posted to OOP by Ehud Lamm on 10/23/03; 3:27:24 AM Discuss (1 response)

HydroJ: Object-Oriented Pattern Matching for Evolvable Distributed Systems

From Craig Chambers, et al. at the University of Washington comes HydroJ... In an evolving software system, components must be able to change independently while remaining compatible with their peers. One obstacle to independent evolution is the brittle parameter problem: the ability of two components to communicate can depend on a number of inessential details of the types, structure, and/or contents of the values communicated... We present HydroJ, an extension of Java that addresses this problem. In HydroJ, components communicate using self-describing, semi-structured messages, and programmers use pattern matching to define the handling of messages... To evaluate the design, we have constructed a prototype HydroJ compiler ... and formalized HydroJ's key features in a core language. Posted to OOP by Patrick Logan on 10/15/03; 9:13:47 PM Discuss

Stroustrup's C++ Style Sweet Spot

(via Isaac, in the discussion group) Stroustrup likes to say that C++ is not an OOPL but rather a multi-paradigm languages. Agree with his sentiment or not, it is clear the he ain't no OOP bigot, and this comes out loud and clear in this interview. I am quite fond of this approach, which is quite similar to mine (I am also a great fan of templates/generic programming): Choose the right tool for the job. Use the good parts of OOP (there are a couple), and don't fall into its potential traps. Same with any other "perfect" paradigm... Tasty quotes from the interview: ...use a vector rather than an array. A vector knows its size. (or use Ada) The assumption is that if it is elegant, if it is higher level, it must be slow. It could be slow in a few cases, so deal with those few cases at the lower level, but start at a higher level. In some cases, you simply don't have the overhead. An integer shouldn't be part of a class hierarchy. It doesn't need to. It costs you to put it there. And it's very hard to do elegantly. You can program with a lot of free-standing classes. It's just a data structure. And if it really is a data structure, make it a data structure. (and not a class) Read the whole thing. Posted to OOP by Ehud Lamm on 10/13/03; 12:55:32 PM Discuss (31 responses)

Tuples + Objects + Infosets =Too Much Stuff!

Once upon a time it was possible for every new programmer to quickly learn how to write readable programs to Create, Read, Update and Delete business information. These so-called CRUD applications, along with reporting, were pervasive throughout business and essentially defined IT or MIS as it was called in those days... [Now] THINGS ARE SO COMPLEX YOU NEED AN M.SC. TO PROGRAM CRUD! Eric says this is a great paper, so who am I to argue? Posted to OOP by Ehud Lamm on 10/2/03; 6:01:43 AM Discuss (28 responses)

OO Best Feature Poll
This obviously unscientific poll over on Wiki may be of interest to LtU readers, either as potential voters, or as programming language anthropologists... Posted to OOP by Ehud Lamm on 10/1/03; 3:56:41 AM Discuss (41 responses)

Readable Java 1.5

From Stephen Jungels at OnJava.com "The Java 1.5 proposal offers programmers a false choice between desirable new features and readability. In fact, all of the proposed new features for 1.5 can be represented by clear, unambiguous, and readable constructs without breaking backwards compatibility. In the rest of this article I will illustrate this point by describing three alternative syntaxes I am proposing." Posted to OOP by Patrick Logan on 9/26/03; 8:46:29 AM Discuss (12 responses)

Smalltalk Reports

For many years in the early to mid 1990s Smalltalk seemed destined to become the enterprise application programming language. IBM was behind it. Many enterprises were successfully implementing projects in finance, insurance, healthcare, and elsewhere. During Smalltalk's relative heyday (so far), the Smalltalk Report was an indispensable journal of monthly knowledge. The Smalltalk Journal is now on-line. Note that the initial PDFs on the page are the tables of contents. But the PDFs TOCs are linked to the PDFs for the actual articles. Posted to OOP by Patrick Logan on 9/25/03; 11:30:23 PM Discuss (1 response)

Inherited Traits - Classes Like Never Before

Despite the undisputed prominence of inheritance as the fundamental reuse mechanism in object-oriented programming languages, the main variants--single inheritance, multiple inheritance, and mixin inheritance--all suffer from conceptual and practical problems. In the first part of this paper, we identify and illustrate these problems. We then present traits, a simple compositional model for structuring object-oriented programs. A trait is essentially a group of pure methods that serves as a building block for classes and is a primitive unit of code reuse. The purpose of traits is to decompose classes into reusable building blocks by providing first-class representations for the different aspects of the behaviour of a class. Note that we use the term "aspect" to denote an independent, but not necessarily cross-cutting, concern. Which statement addresses AOP similarities in a nutshell. There is a possibly related paper, "Half & Half: Multiple Dispatch and Retroactive Abstraction for Java," from the Brew Project. Posted to OOP by Mark Evans on 9/11/03; 10:41:23 PM Discuss (12 responses)

DP-COOL 2003 Proceedings

Mark Evans posted this link to the discussion group. Read what he has to say. There are several papers here that may interest LtU regulars (and a couple of papers we already dicussed at length). Here are the ones that caught my attention: Syntax sugar for FC++: lambda, infix, monads and more. Importing alternative paradigms into modern OO languages. JSetL: Declerative Programming in Java with Sets. Posted to OOP by Ehud Lamm on 9/8/03; 3:34:09 AM Discuss (5 responses)

Implementing Business Rules in the BC4J Framework

Steve Muench posted this link on his BC4J weblog. This Oracle whitepaper can serve as an introduction to business rules, as they are currently understood in mainstream software projects. I am a bit reluctant to accept the notion of business rules used here, since it can lead to a kind of myopia resulting in applications having less sophisticated logic, and supporting trivial domain specific abstractions. I find it sad to think that all business software products are simply instances of such a trivial set of rule categories. Compare with cool software design (in the sense used here), like this one. A fair question at this point would be why is all this relevant to LtU, a programming languages weblog. I am not sure exactly, but I have a feeling the discussion will help answer this question. What I do know is that this whitepaper is relevant to some of the issues discussed here recently: IDEs, UML (and OCL), OOP's interaction with relational models, and finally declerative programming. Posted to OOP by Ehud Lamm on 9/6/03; 8:52:54 AM Discuss (11 responses)

Kata Two: Iteration, Recursion and Continuations

As long as I'm mining his site, I thought I'd link to the more involved series that Jim Weirich put together that serves as nice introduction to continuations. In conjunction with Dan Sugalski's talks about Continuations, CPS, TailRecursion, and more, I might just be able to figure out how to get the CallCC function to work in my unlambda interepreter. :-) PragDave has put together some programming "practice" exericises that he calls Katas. In Kata number two he suggests writing a binary search function, not once, but five different ways. Now I’ve implemented a binary search several times, but writing it five times in five different ways was intriguing. Iterative with Loop Invariants Recursive Recursive with Explicit Limits Continuation Passing Style Eliminating Tail Recursion The series of implementations given is a nice perspective on the different styles used solving the same problem - thus giving a fair basis for comparison. Posted to OOP by Chris Rathman on 8/31/03; 8:52:54 PM Discuss

Using Ruby

An Introduction to Ruby for Java Programmers. This a presentation that Jim Weirich is giving to introduce Ruby to those unfamiliar with the language. Pretty good at wheting the apetite, but the slides that caught my eye were the ones concerning typing: There are a lot of choices when designing a type system Strong vs Weak Strong: Impossible to treat an object as an wrong type Weak: Possible to use improper operations on an object Static vs Dynamic Static: The type of an expression is known at compile time. Dynamic: The type of an expression is only known at run time. Explicit vs Implicit Explicit: All variables and functions are explicitly typed (also called Manifest typing) Implicit: The types of variables are implicit (also called Latent typing) Nothing earth shattering but since there's been some discussion about the usefullness of the term "dynamic typing", I thought the breakdown might be useful. Posted to OOP by Chris Rathman on 8/31/03; 7:40:43 PM Discuss (14 responses)

Maybe Erlang is OO after all?

Joe Armstrong posted this message to the erlang-quesions mailing list: Thus it might be argued that: - Erlang *is* OO and - Erlang is *more* OO than any of the other so called OO languages Put that in your pipe and smoke it! On first glance it might seem that this is more appropriate for the fun department, but the thread that followed this initial message contains some interesting discussion about what OOP is all about. Posted to OOP by Ehud Lamm on 8/25/03; 2:12:47 AM Discuss (4 responses)

Memoization in Java Using Dynamic Proxy Classes

Memoization has been touched on number of times on LtU, but rarely in connection with Java. Memoization is a technique borrowed from functional programming languages like Lisp, Python, and Perl for giving functions a memory of previously computed values. Memoizing a function adds a transparent caching wrapper to the function, so that function values that have already been calculated are returned from a cache rather than being recomputed each time. Version 1.3 of the Java™ 2 SDK, Standard Edition, introduced support for dynamic proxy classes: special classes that can choose which interfaces they implement when created at runtime... By using this feature, it is possible to write a generic caching wrapper class, called Memoizer, that determines at runtime which interface it implements. Can't say that I liked the method chosen for dynamic proxies in Java. A bit too long winded and cumbersome for my taste. Good to see that someone is trying to put them to use for something. Posted to OOP by Chris Rathman on 8/21/03; 5:44:51 PM Discuss (3 responses)

The Trouble with Checked Exceptions

This is the second in a series of interviews of Anders Hejlsberg at Artima as discussed in a previous LtU thread. Anders weighs in on the subject of Java's checked exceptions. It is funny how people think that the important thing about exceptions is handling them. That is not the important thing about exceptions. In a well-written application there's a ratio of ten to one, in my opinion, of try finally to try catch. Or in C#, using statements, which are like try finally. In the large, checked exceptions become such an irritation that people completely circumvent the feature. They either say, "throws Exception," everywhere; or—and I can't tell you how many times I've seen this—they say, "try, da da da da da, catch curly curly." They think, "Oh I'll come back and deal with these empty catch clauses later," and then of course they never do. In those situations, checked exceptions have actually degraded the quality of the system in the large. I can't say that I agree with his assessment. First off, I don't think that recompilation is the same thing as altering code. Any client code that handles general exceptions or drops into a finally clause is already code ready. If the compiler regenerates the code and gives it a new version, then it's the compiler's fault for not recognizing the binary did not change with the new version. Also, I believe that exceptions thrown are part of the interface, just as much as the return value of a function itself. If a function is given a total new class of exceptions, then it's likely that there is a reason to uniquely propagate those exceptions. If it's just a refinement, then the exceptions can be subclassed and handled polymorphically as if they were the same as the original specified exceptions. Posted to OOP by Chris Rathman on 8/18/03; 4:59:28 PM Discuss (37 responses)

JDO Architectures

In this excerpt from Java Data Objects, authors David Jordan and Craig Russell provide a high-level overview of the architectural aspects of JDO, as well as examples of environments in which JDO can be used. Hiding the databse behind a good abstraction is one of the hard problems of software design. Languages can help, but are yet to provide a complete solution. I am not sure just how useful this chapter would be to anyone, and I haven't seen the whole book. Still, this item may prompt a discussion of this important area which includes issues like persistency, transaction processing, linguistic abstractions and more. To get things going, here's a question: How would you design an API that would enable programmers to combine some non-relational data store, with normal SQL queries (assume the data model of the non-relational data store is given). The goal is to make the fact that the non-relational data store is, in fact, not relational, as transparent as possible, so as to allow programmers to use standard tools, and reduce their, er.. how should I put it, cognitive burden Any suggestions? Posted to OOP by Ehud Lamm on 8/4/03; 6:21:25 AM Discuss (17 responses)

Gregor Kiczales on Aspect Oriented Programming

Gregor Kiczales lead the PARC team that developed AOP and AspectJ. He is a well-known evangelist for AOP, focused on building both the practioner and researcher communities. He has 20 years of experience in developing advanced programming technologies and delivering them into the hands of developers. He was a member of the ANSI CLOS design team, the implementer of the reference implementation of CLOS, the lead designer of the CLOS metaobject protocol and a co-author of "The Art of the Metaobject Protocol". The ServerSide has an interview with Kiczales and an accompanying Threaded Discussion. Worth a read for anyone wanting to know the thinking that has gone on in the AOP world. (Kiczales has been previously mentioned on LtU in relation to MOP/AOP). Posted to OOP by Chris Rathman on 7/28/03; 2:27:58 PM Discuss (4 responses)

Message Object Oriented vs Function Object Oriented

In a conversation in another forum, the question came up whether Smalltalk's messaging view of the interaction between objects has a correlary in the Static Typing world. Specifically, is the concept of capturing #doesNotUnderstand and doing creative dispatching something that's anathema to static type checking? The Message oriented languages (of which I know Smalltalk and Objective C) make objects act essentially like servers - when messaged they can simply handle the message, ignore the message, forward the message, or signal a fault. The messages themselves are available as a chunk of data to examine, or modify as necessary. Messages are sent to an object's handler ("method" if you like), or to #doesNotUnderstand: if no handler exists. What you want to do in there is your business but the default is to halt the process and slap a debugger around it... This mechanism makes possible a number of very powerful techniques that are simply beyond the ken of the average function calling language user. ...the message can be reified as data and manipulated, and the mapping between message and method is looser and can be something other than a simple name/signature mapping. Posted to OOP by Chris Rathman on 7/22/03; 10:34:37 PM Discuss (2 responses)

Godiva - a Very High Level Dialect of Java

Godiva is a dialect of Java that provides general purpose abstractions that have been shown to be valuable in several very high level languages. These facilities include additional built-in data types, higher level operators, goal-directed expression evaluation, and pattern matching on strings. Godiva's extensions make Java more suitable for rapid prototyping and research programming. Adding these features to the core language increases the expressive power of Java in a way that cannot be achieved by class libraries. A bunch of ideas from Icon and APL grafted onto Java. Here's the link to the language reference. There doesn't seem to be an implementation available. Posted to OOP by Bryn Keller on 7/16/03; 6:10:03 PM Discuss (4 responses)

Object-Oriented Style

Object-Oriented Style (.ps). Daniel P. Friedman. Invited Talk at International LISP Conference, October 12-15, 2003. In this paper, we develop a way of managing objects. We present object-oriented style, a few operators to make the style easier to read, and a few protocols to maintain some control over the style. We then enforce the style and the protocols with an optional macro. Reductionism run amok? No. It's simply Scheme all the way down... Posted to OOP by Ehud Lamm on 7/14/03; 3:47:28 AM Discuss (2 responses)

Partial Types in C#

Partial Types were mentioned in a previous post. Can't say that I find the feature appealing - I think the enforced style of a single source file was a good thing in Java. Be nicer if they borrowed the Category concept from Objective-C, allowing one to add methods to classes that you don't have source for - such as the base libraries. Problem with the proposed C# extension is that both parts of the class definition require the use of the Partial keyword. No way to add methods to a class that is not considerate enuf to allow extension. Posted to OOP by Chris Rathman on 7/11/03; 10:14:05 AM Discuss (7 responses)

Preview of Java 1.5

An early access prototype implementation of the proposed new J2SE 1.5 language features is available. The prototype includes generics (JSR 14), typesafe enums, varargs, autoboxing, foreach loops, and static import (JSR 201). In other words, all the new language features planned for 1.5 except metadata (JSR 175). Many of the new features have been previously discussed here. Now we can finally play with them. Posted to OOP by Dan Shappir on 6/1/03; 1:19:39 AM Discuss (2 responses)

Variance in Java Generics
This link was posted to the discussion group and while I haven't really had the chance to explore this in any detail, the proposal sounds interesting. I'd like to hear more, if anyone has any thoughts he'd like to share. Posted to OOP by Ehud Lamm on 5/29/03; 1:01:42 PM Discuss (2 responses)

Naked Objects
Exposing objects as GUI. This is a Java library, but of course there's a Smalltalk connection - I found the site via this this post by Alan Kay to squeak-dev, which has a brief history of this kind of thing. Posted to OOP by andrew cooke on 5/25/03; 11:11:40 AM Discuss (16 responses)

The New C++: Trip Report, October 2002

I'm going to spend this column reporting on happenings at and around the most recent C++ Standards meeting, because things are now heating up, at least a little. In particular, the first two proposals for C++ Standard library extensions have now been accepted by the committee - and it's something of a breakthrough, in that this represents the first new work to be accepted since the first round of standardization was completed in 1997! Herb Sutter reports on the wild going-ons at the C++ Standards committee (registration may be required to view this article). They are actually considering new extensions to the C++ language! The many fans of C++ here can find more information at the ISO C++ committee's website. Posted to OOP by Dan Shappir on 5/5/03; 12:17:20 PM Discuss (24 responses)

C# Programming Language Future Features

I haven't seen this one on LtU yet. The Microsoft Corporation is in the process of developing the next major version of the C# language. This article contains information regarding four key new features, including generics, iterators, anonymous methods, and partial types. Additional info can be found at GotDotNet. There is also an article about Visual C# .NET 2003 Language Changes, with the following amusing quote: In an effort to remain 100% compliant with the European Computer Manufacturer's Association (ECMA) C# specification, Microsoft Corporation introduced several changes to its implementation of the C# compiler. and finally a transcript of an online chat regarding future directions for C#, which doesn't provide much of interest IMO. Posted to OOP by Dan Shappir on 4/6/03; 6:56:24 AM Discuss (3 responses)

Copying and Comparing: Problems and Solutions

Grogono, P., and Sakkinen, M. Copying and comparing: Problems and solutions. In ECOOP'00, E. Bertino, Ed. Springer-Verlag, Cannes, France, June 2000. Saw this paper mentioned on the ll1 mailing list. This is an important issue, and the paper makes for ok reading. Section 5.2 gives language design guidelines that are worthy of consideration. Ada isn't discussed in the paper, which is a shame. Ada makes a basic distinction between limited and non-limited types. Limited types (which include types the user marks as limited as well as things like tasks and protected types) don't provide equality and assignment operations. For non-limited types deafult assignment and equality operations are defined. The equality function can be overloaded, where as the semantics of assignment can be changed by supplying an appropriate procedure (called Adjust). Posted to OOP by Ehud Lamm on 4/1/03; 6:48:04 AM Discuss (1 response)

Java object models debated

InfoWorld reports on a panel discussion at the Software Development Conference & Expo West 2003 in Santa Clara, CA, on the topic "J2EE EJBs do not support complex object models -- what to do": Versant CTO Keiron McCammon stated that Entity Beans technology doesn't solve the problem. "That's my position and I'm sticking to it," McCammon said. "They quite frankly just built the clock wrong." Floyd Marinescu [of TheServerSide.com] also said he had difficulties with Entity Beans. "It is still hard to build large object models with Entity Beans," Marinescu said. The opportunity to build a market of reusable business components has not happened, he said. "It was an admirable dream but it didn't pan out," Marinescu said. Entity Java Beans are not actually a language feature, but there's a close connection to language issues. For example, have EJBs in fact suffered by not exploiting language features, such as reflection, in order to support more transparent persistence? Posted to OOP by Anton van Straaten on 3/26/03; 11:45:44 PM Discuss (9 responses)

Is Inheritance a Pillar of OO?

An interesting, or at least amusing, discussion about inheritance and its importance to OOP In my (limited) experience, nobody at a university has any clue as to what OOP really is about. In one "advanced" Java class, the professor once said that he had never been able to find a purpose for inheritance and that it would be best not to use it... Posted to OOP by Dan Shappir on 3/12/03; 9:50:56 AM Discuss (38 responses)

Open Implementations and Metaobject Protocols

Gregor Kiczales, Andreas Paepcke Discusses opening up substrate software (object systems, databases, operating systems) by adding reflective "side-door" protocols that allow the client to change the behavior of the system. A tour-de-force of good software design. Contracts, ease-of-use, common sense, and performance are emphasized. As an example, the not-so-tiny TinyObjects ("the common core of C++, Smalltalk, CLOS and Objective-C") is systematically opened and extended for fundamental change by clients. [...] this book does not propose that substrate software should just "have more features to please more programmers." Instead, it suggests that substrates should be open in a way that allows programmers access to and control over the substrate's implementation in a way that allows the programmer to tailor the substrate to the needs of a particular application. This is called open implementation. Will this be such a powerful tool that application programmers will be able to "machine gun themselves in the foot?" To me, an extremely interesting and insightful book, and maybe an outlook to Intentional Software's upcoming tools. Posted to OOP by Manuel Simoni on 2/17/03; 4:49:32 PM Discuss (9 responses)

Designing Reusable Classes (PDF)

Ralph E. Johnson, Brian Foote A solid write-up of some OOP best practices. First, tackles general terms such as Inversion of Control (you don't call us, we call you) and White-Box vs. Black-Box frameworks (the former requiring implementation knowledge, the latter not.) Then presents a list of methods for improving OO code, such as Recursion introduction (giving related messages similar names, even if they have different parameters), Eliminate case analysis (if the same ifs and elses repeat throughout your code, you've probably missed an abstraction), Class hierarchies should be deep and narrow and Reduce implicit parameter passing. None of these points are really new and some may be debatable, but overall the paper is a good guide for those looking for the tao of objects (then again, the tao that can be seen is not the real tao.) A nice quote is "type" should be thought of as protocol and not as class, but I don't want to get anyone started on that again ;) (There seems to be a longer HTML version of this document here.) Posted to OOP by Manuel Simoni on 2/13/03; 9:47:27 PM Discuss (7 responses)

Why We Refactored JUnit

One difference between JUnit and Artima SuiteRunner is that in JUnit, the notion of results reporting is linked to the notion of running test suites. For example, to generate test results as text, you use JUnit's text runner. To generate graphical test results, you use JUnit's Swing runner. By contrast, Artima SuiteRunner separates the notion of running from that of reporting. In Artima SuiteRunner, we provide one runner that can be configured with multiple reporters. Each reporter presents customized test results: for example, a text reporter presents results as text, a graphical reporter presents results graphically. A nice story about unit testing, JUnit, and test automation. Not exectly earth shattering, but it has been ages since we had an OOP link here. I guess the reason for that is that I am not really doing OOP these days, and that the other editors are neglecting their duties... Posted to OOP by Ehud Lamm on 2/7/03; 10:59:18 AM Discuss (4 responses)

Java and Pointers

Keith posts some nice links about the Java-doesn't-have-pointers language myth. Why did I put this message in the OOP department? Well, using reference semantics is something OOP languages do, some may even say it's something compiled OOPLs have to do -- but I still find it ugly. We work so hard to establish abstraction boundaries, only to have programmers return references to internal arrays and such by mistake. Well, anyway, that's life. Posted to OOP by Ehud Lamm on 1/14/03; 1:06:31 AM Discuss (7 responses)

Abstract Iterable Pattern Matching for Java (JMatch)

The JMatch language extends Java with support for abstract iterable pattern matching: a mechanism for pattern matching that is compatible with the data abstraction features of Java and also makes iteration abstractions convenient to use and to implement. JMatch provides abstract pattern matching; patterns are not tied to algebraic data constructors as in ML. A single JMatch method may be used in several modes that may share a common implementation as a boolean formula. JMatch provides modal abstraction that simplifies the specification and implementation of abstract data types. JMatch also makes the specification, implementation, and use of iteration abstractions convenient, by automatically finding multiple solutions to a formula or pattern. We are used to seeing pattern mathcing facilites in functional languages, however the design of JMatch is in some respects closer to the classic pattern matching facilities found in logic programming languages. In particular, method parameters can serve a dual role: for some calls they are treated as input parameters, and in others the same parameters are treated as output parameters and computation is reversed. It seems that the JMatch approach, by making Java more declerative, helps specify the algebraic properties of ADTs more consistently than is possible using just imperative code. JMatch is implemented using the Polyglot extensible Java compiler framework. Posted to OOP by Ehud Lamm on 1/6/03; 2:45:43 PM Discuss (2 responses)

Model Driven Architecture + Code Generation

A nice introduction to Model Driven Architecture (MDA). This is not really a langugae issue but language designers and implementors should take notice of the fact that many programmers prefer to use drawing tools rather then compilers The article lists ten myths about code generation and code generation tools. In industry you often find the deparment responsible for building langugae tools (DSL processors and the like) also responsible for IDEs and GUIs that rely on code generation. And even if building such tools isn't something you do daily, you may find yourself having to process code that was generated by such systems. Alex has some comments about myth 7: I'll just use XML/XSLT and be done with it. Posted to OOP by Ehud Lamm on 12/24/02; 3:15:02 PM Discuss (5 responses)

Squeak projects (and project ideas)
Anthony Hannan is looking for a research position or PhD program. Along the way he has done some interesting things with Squeak, and posted a nice write-up to the Squeak Swiki. A few things that caught my eye: Closures and Faster Contexts, Multiple Inheritance, Distributed Objects and Reliable Persistence. Posted to OOP by Ehud Lamm on 12/11/02; 3:31:28 PM Discuss

Introducing C#, Present and Future
The OOPSLA presentation on the new C# features is now available, including the dmeo files. Am I the only one who thinks that types should not be required at run time? Posted to OOP by Ehud Lamm on 11/18/02; 3:42:59 AM Discuss (6 responses)

Objects and classes versus modules

Xavier Leroy. Objects and classes versus modules in Objective Caml. ICFP'99 This talk was mentioned in a LtU discussion titled "A Good OOP Critique." This talk, however, delas with a much more specific issue. I am often asked about the distinction between modules and classes, and between ADTs and objects. I am sure I'll be asked again, so it might be useful to remember that these slides exist... Does Pierce's book discuss this issue? I recently came across draft notes of his about types systems, that discuss this issue explicitly (chp. 13.2.3) Posted to OOP by Ehud Lamm on 11/16/02; 2:18:33 AM Discuss (2 responses)

Strongtalk

Strongtalk is a major re-thinking of the Smalltalk-80 language and system. While retaining the basic Smalltalk syntax and semantics, it contains a number of significant advances, including: Performance: It executes Smalltalk much faster than any other Smalltalk implementation, using an advanced inlining compiler based on type-feedback technology. Type System: It contains the first fully developed strong, static type system for Smalltalk (hence the name Strongtalk). The type system is both optional and incremental, and operates completely independently of the compiler technology (which means that normal untyped Smalltalk code runs just as fast as typed code). It also contains a re-designed, strongly-typed "Blue Book" class library. Marcus Denker was kind enough to alert my attention to this interesting work, when I asked about advances in JIT technology. If I understand correctly some of the implementation techniques from Strongtalk made their way to Sun's Hotspot VM. Posted to OOP by Ehud Lamm on 10/31/02; 5:15:52 AM Discuss (12 responses)

Jakarta-Commons Collections Component

...there are certain holes left unfilled by Sun's implementations, and the Jakarta-Commons Collections Component strives to fulfill them. Among the features of this package are: Special-purpose implementations of Lists and Maps for fast access Adapter classes from Java1-style containers (arrays, enumerations) to Java2-style collections. Methods to test or create typical set-theory properties of collections such as union, intersection, and closure. An interesting collection of Collections. Another example of using the java.util interfaces. Posted to OOP by Ehud Lamm on 10/22/02; 6:15:02 AM Discuss (3 responses)

F-Script: Smalltalk Scripting for Mac OS X
Philippe Mougin. F-Script: Smalltalk Scripting for Mac OS X. ESUG 2002 F-Script is a scripting language that was inspired by both Smalltalk and APL. The language was discussed here previously. These slides show how F-Script is integrated with Cocoa (the OS X framework). Compressed PPT file. Posted to OOP by Ehud Lamm on 10/17/02; 6:33:51 AM Discuss (1 response)

MultiJava: Design, implementation, and evaluation

This master's thesis describes a multiple dispatch extension to Java that makes Java more Lisp/CLOS-like. The extension: ...supports open classes and symmetric multiple dispatch. An open class is one to which new methods can be added without editing the class directly. Multiple dispatch allows the method invoked by a message send to depend on the run-time types of any subset of the argument objects. MultiJava is the first full-scale programming language to support these features while retaining modular static typechecking and compilation. Method polymorphism in Java and the distinction between single and multiple dispatch is explained with examples in Multi-Dispatch in the Java Virtual Machine: Design and Implementation, Dutchyn, Lu, Szafron, Bromling and Holst . (MultiJava: Design, implementation, and evaluation of a Java-compatible language supporting modular open classes and symmetric multiple dispatch, Curtis Charles Clifton, 2001) [MultiJava Project Homepage] Posted to OOP by jon fernquest on 9/21/02; 4:10:54 AM Discuss

Automatic Run-time Interface Building

(via Daily Python-URL) ...there is often a large barrier to object composition - sometimes a class needs to have the interface of its components. You don't want to extend the functionality of the component, you just want its interface, and you want all calls to that interface to be sent to the component object. In this case, it is so much easier to inherit even though you are not really extending the functionality of the parent class... Amazingly enough, however, Python allows you to modify classes at run time. This means it is possible to make Python automatically write these wrapper (or proxy) functions for you. Lateral thinking at its worst? Posted to OOP by Ehud Lamm on 9/18/02; 10:45:48 AM Discuss (3 responses)

Introduction to the Personal Basis Profile

The newly-released Personal Basis Profile (PBP) provides a Java runtime environment with network connectivity and basic graphical presentation for high-end PDAs, set-top boxes and other devices. PBP applications can use floating-point values, object finalization, and other features missing from the CLDC... The PBP also incorporates all the features of the Foundation Profile (FP), including the many core J2SE classes the FP adds to the smaller set that the CDC specifies.... the PBP does not specify familiar UI components like buttons, menus, or listboxes - and the leanness of the specification is quite intentional. The PBP is meant to support a wide variety of UI component sets, on devices of many different kinds. The expectation is that applications will rely on toolkits that provide lightweight components appropriate to a target category of devices. Another recent article describes the new Xlet application model for the profile. Posted to OOP by jon fernquest on 9/11/02; 3:20:32 AM Discuss (3 responses)

Diagnosing Java code: Assertions and temporal logic in Java

Qualifies assertions with modal operators from temporal logic: Always, Sometime, Until, Next. "In the case of digital circuits, assertions like these are statically verified before the chip is built... In the case of software, our ability to statically check such assertions is paltry, but quality tools exist for checking that these assertions hold during particular runs of the program (such as, say, the runs of your unit tests). Assertions like these can help you to leverage unit testing to a much greater degree; each temporal logic assertion can correspond to countless traditional assertions (and that's just in cases where traditional assertions could be used to express the assertion at all." Unfortunately only commercial software is currently available to do these checks. The next article in the series "Preventing common bugs with temporal logic assertions" puts the modal operators to use on different types of bugs. Posted to OOP by jon fernquest on 8/30/02; 3:50:07 AM Discuss

Project JOOS (Java's Object Oriented Subset)

Features a compiler for a small manageable subset of Java ideal for teaching and research (Action Semantics). If you've ever dreamed of pruning Java back, forking it, and growing it yourself with a new set of features (e.g. functional) [ O'Reilly Java3 Article, LTU Java Critique ] this seems like a good place to start. Developing a JOOS Compiler Using a SableCC Framework (Alaoui, 2000) provides a detailed description of the Java implementation of JOOS. There are no packages, interfaces, exceptions, mixed statements and declarations, or switch statements, "fields can only be protected, methods and constructors can only be public; methods cannot be overloaded, only constructors can; arrays are not supported (this can be made up for by using Vector objects); the main method is the only allowable static member in a class; primitive types for real numbers are not supported." External declarations, similar to C's, allow you to use Java libraries and even add Java language features to JOOS: "JOOS also provides its own library of precompiled class files for interfacing to functionality supported only in Java (e.g. constants, static methods and static fields)." There even seems to be a logical place to insert an Abstract Syntax Tree editor for source code transformation and refactoring like Intentional Programming does. Abstract Syntax Trees's are "built by the parser, using the semantic actions specified in the grammar file... The compiler then performs the usual passes on the AST, and each pass is explicitly and manually implemented as a recursive descent of the syntax tree." (Alaoui, 4-5) Posted to OOP by jon fernquest on 8/23/02; 2:24:48 AM Discuss (1 response)

Ada, Interfaces and the Listener Paradigm

J-P. Rosen. Ada, Interfaces and the Listener Paradigm. Lecture Notes in Computer Science, No. 2361. Proceedings of the Reliable Software Technologies - Ada-Europe 2002 conference. Talking about the OOP features in Ada95, people may find this paper interesting. The author shows how to build listeners, and along the way gives a design pattern for interfaces in Ada. The papers shows technqiues that enable multiple inheritance-like functionality in Ada95 -- a single inheritance language (cf. Taft '92 LSN). Posted to OOP by Ehud Lamm on 8/20/02; 12:40:35 PM Discuss

Alloy: A Lightweight Object Modelling Notation

A small strongly typed language built upon rigorous semantics and ideas from the Z specification language [Home Page, Definition]. The question posed by the author: "What is the smallest modelling notation that can express a useful range of structural properties, is easy to read and write, and can be analyzed automatically?" Alloy supports the description of basic structure (graphically, or as textual declarations), as well as more intricate constraints and operations describing how structures change dynamically (both expressed as logical formulas)... Alloy is not for describing dynamic interactions between objects, nor for describing syntactic structure in an implementation, such as the class hierarchy and packaging... Alloy is amenable to a fully automatic semantic analysis that can provide checking of consequences and consistency, and simulated execution. To gain ‘executability’, Alloy does not sacrifice abstraction: it can generate sample transitions of an operation described implicitly, using negation and conjunction." A file system is used as an example. A comparison is made to UML and UML's Object Constraint Language. A critique of how Z's reliance on Latex has limited its widespread use is also given. See the Authors Home Page for software download, talks, publications, and access to a Yahoo discussion group. Posted to OOP by jon fernquest on 8/12/02; 2:05:58 AM Discuss

10 Reasons We Need Java 3.0

How would you shrink Java and rebuild it? This article imagines a "Java 3" that jettisons the baggage of the last decade, and proposes numerous changes to the core language, virtual machine, and class libraries. The focus here is on those changes that many people (including the Java developers at Sun) would really like to make, but can't -- primarily for reasons of backwards compatibility. 1. Redesign class loading from scratch. 2. Redesign I/O. 3. Rationalize the collections. 4. Ditch the AWT. 5. Convert file formats to XML. 6. Fix threads. 7. Extend chars to four bytes. 8. Eliminate primitive data types. 9. Fix incorrect naming conventions. 10. Delete all deprecated methods, fields, classes, and interfaces. Posted to OOP by jon fernquest on 8/10/02; 12:32:54 AM Discuss (1 response)

Guiding Visitors: Separating Navigation from Computation

Operations on abstract syntax trees are an important application of the Guide pattern which goes beyond the Visitor pattern and separates "navigation from computation and object structure": "A guide is an object that captures a traversal scheme through an object structure.... the notion of top-down or bottom-up traversal can be captured by a guide and used in visitors for pretty-printing, collecting components by predicates, transforming a structure etc." A simple example, counting the number of leafs in a tree, is rewritten several times gradually uncoupling navigation from the Visitor computation and object structure and discussing the implementation of similar libraries such as JJForester, JJTree [1, 2], Java Tree Builder, and Walkabout. A Generic extension to Java is used because "parameterised types allow us to parameterise a class with another class. This will prevent many type casts, especially when working with collections." (an early-access implementation of the Java 2 SDK 1.5 compiler is used). The paper also mentions an extension of the JRefactory refactoring tool to "collect the exceptions that are caught around a set of statements." Posted to OOP by jon fernquest on 7/25/02; 1:36:34 AM Discuss (4 responses)

Java Collections Clearinghouse

The purpose of the Java Collections Clearinghouse (JCC) site is to exchange Java Collections API implementations and Java DataTransfer API implementations among the Java development community. The Java Collections Framework in Java 2 is a very powerful set of data structures and has the most commonly used data structures built in. However, it provides interfaces which can be used to write even more data structures. This site is designed for housing these data structures. One of the things that I really like about the Java Collections is the clear separation of interfaces and implementations. This site shows one reason why this is such a good idea. Please note that as general design direction for container libraries I prefer genericity (ala the STL) to inheritance. Still, interfaces should be clearly defined, separate, entities. Posted to OOP by Ehud Lamm on 7/12/02; 3:03:16 AM Discuss (1 response)

Are dylan macros Turing-complete?

This is a UseNet thread about the Dylan macro facilities with some examples showing that macros can be a language onto themselves. With some discussion of the limitations of Dylan macros compared to those in Common Lisp. Bruce Holt: I find the ability for a single macro to expand into methods added to any number of Generic Functions to be incredibly powerful. I don't think this is matched by any other language other than CL. To me this is key to a large part of the power of Dylan macros and, combined with Dylan's sealing declarations and a powerful optimizing compiler, can do many things efficiently that would otherwise require full programmable code generation such as "aspects". Me, I'm still on a tangent trying to figure out Dylan's use of module and library commands (macros?) and the relationship they have with the actual files. From what I gather, Dylan allows you to define different interfaces to a particular module based on the criteria of the user (sort of like Modula3 classes). But I can't seem to get my head wrapped around the specifics. Posted to OOP by Chris Rathman on 5/9/02; 6:54:59 AM Discuss

Frost - Multimethods and FWVAs for C++
Frost allows you to use multi methods and virtual function arguments in your C++ programs as if they were a native C++ feature. Seen at sweetcode and not present in a site search of lambda. Posted to OOP by andrew cooke on 5/8/02; 5:04:23 PM Discuss

OO Tips

The purpose of ootips is to allow developers to keep up-to-date with object oriented technologies, without having to read through high volume, low signal-to-noise sources. I try to extract the most useful and interesting posts from other mailing lists, newsgroups and web forums, and post about one article every week or two. I've had this page bookmarked for some time and thought I'd pass it along. The site is a condensed version of some of the discussions and arguments about OOP that have taken place on UseNet over the years. Posted to OOP by Chris Rathman on 5/7/02; 9:09:07 PM Discuss

Modern Concurrency Abstractions for C#

This is a paper from Luca Cardelli & company at Microsoft Research that proposes the C# language extension of Polyphonic C#. It offers up some modifications to C# to provide "asynchronous concurrency constructs, based on the join calculus". We believe that concurrency should be a language feature and part of language specifications. Serious attempts in this direction were made beginning in the 1970's with the concept of monitors and the Occam language. The general notion of monitors has become very popular, particularly in its current object-oriented form of threads and object-bound mutexes, but it has been provided at most as a veneer of syntactic sugar for optionally locking objects on method calls. From the looks of it, the solution is not too invasive on the language, offering up only two new language constructs - Asynchronous Methods and Chords. Async methods resemble (and are partially interchangeable) with void functions (i.e. procedures). The function returns immediately - with no result - and continues processing in a seperate thread. Chords are a combination of a normal method with an async method, providing a method to join with an async method - both are declared together to syntactically bind the methods. Posted to OOP by Chris Rathman on 4/30/02; 9:42:22 PM Discuss (4 responses)

The MultiJava Project

a backward-compatible extension to The Java Programming Language that supports open classes and symmetric multiple dispatch. An open class is one to which new methods can be added without editing the class directly. Multiple dispatch allows the method invoked by a message send to depend on the run-time types of any subset of the argument objects. This project shares some of the same goals as AspectJ but is much less disruptive - trying to maintain modular reasoning in the process. I've been trying to get a feel for the language extensions but have been unable to get the external top level functions to be recognized as part of the base class. In AspectJ terminology, Open Classes are similar in effect to Introductions. MultiJava, however, doesn't allow one to tack on method definitions or implementations to interfaces - strictly applying to classes. MultiJava doesn't have the concept of wildcards to apply the implementation to more than one class at a time. Also, MultiJava currently limits introduction to instance functions - not allowing introduction of state, constructors or static methods. All in all, Open Classes are much more limited than the introduction framework provided by AspectJ. That said, MultiJava does have the advantage of providing multi-methods. The language allows dispatch on the argument types of the functions using the Type@VarName qualifier on qualifier in the parameters. Posted to OOP by Chris Rathman on 4/27/02; 8:38:55 PM Discuss (4 responses)

AOP: The 15% Solution

A short interview with Gregor Kiczales of the Parc team that developed Aspect Oriented Programming and AspectJ. A group here at PARC has been looking at ways to improve software architecture. For about 12 years, we've been thinking that crosscutting was "it." We first worked on reflection and metaobject protocols. That had almost too much power; people couldn't make effective use of it. Then, around 1992, John Lamping and I took another stab at how to capture crosscutting. Over a series of years, we developed AOP and AspectJ. I can't say that I'm completely sold on AOP just yet. While it's true that OOP's reliance on hierarchical data structures is a weakness, I'm not sure opening that structure to crosscutting aspects (parasites?) makes reasoning about them any easier. That said, I do see 3 primary advantages of AspectJ: (1). It's very nice for tracing, monitoring, and debugging; (2). Visitor and Observer patterns become a whole lot less cumbersome; and (3). it allows implementation methods to be defined for Interfaces (Obligatory toy code). But there's probably some other things I'm missing as well... Posted to OOP by Chris Rathman on 4/20/02; 3:54:52 PM Discuss (11 responses)

GOO: a generic-function based OO language
Really interesting thread in our discussion group. The language looks worth investigating (one more thing to add to that growing TODO list...) We need more threads like this one! A big thanks to Michael for posting this, and to Chris Rathman for making the discussion more substantive, by giving example code! Posted to OOP by Ehud Lamm on 4/19/02; 1:39:34 PM Discuss

ENVIRONMENTAL ACQUISITION - A NEW INHERITANCE MECHANISM

(via Smeed/Udell/Udell) ENVIRONMENTAL ACQUISITION - A NEW INHERITANCE MECHANISM. J. Gil and D. Lorenz. Technion Tech. Report LPCR9507 Nature vs. Nurture? The debate has obsessed the minds of psychologists and philosophers for many years. However, for the object-orienteer, it has never been a problem: an object inherits all of its properties. In this work we ask if an object should not be subject to environmental effects. We answer this question in the affirmative by demonstrating many cases in which the character of an object must be affected by the environment it is put in. We present a new abstraction mechanism - Environmental Acquisition - which allows a component to inherit properties from its enclosing composite(s). The need for environmental acquisition is demonstrated in several application domains. It is shown that the absence of environmental acquitision may lead to the creating of cumbersome programs. We propose a strongly typed model for environmental acquisition that allows static type checking of programs exploiting this mechanism, and compare it to several other mechanisms including ordinary inheritance and delegation. I don't have the time to read this right now, but the first few pages seem interesting (and I like some work from the same authors, which I did read). The relation to Zope (see the Byte column by Udell) is interesting. Can anyone elaborate on this? Posted to OOP by Ehud Lamm on 4/17/02; 12:27:28 PM Discuss (1 response)

Modern Concurrency Abstractions for C#

Luca Cardelli, Modern Concurrency Abstractions for C#. ECOOP'02 to appear. Polyphonic C# is an extension of the C# language with new asynchronous concurrency constructs, based on the Join Calculus. We describe the design and implementation of the language and give examples of its use in addressing a range of concurrent programming problems. I am not sure if I like the approach. Perhaps the problem is that I am used to the more explicit Ada approach, but I find some of the examples a bit confusing. Posted to OOP by Ehud Lamm on 4/12/02; 11:32:21 AM Discuss

Foundations of Object-Oriented Programming Languages

(via the Types Forum) Foundations of Object-Oriented Programming Languages: Types and Semantics. Kim B. Bruce. The MIT Press. ISBN 0-262-02523-X The target audience for the book includes researchers, graduate students, and others interested in understanding the types, semantics, and language design issues relevant to the study of object-oriented languages. Five chapters are available online. Chpater 3, Type Problems in Object-Oriented Languages looks promising: We begin our study of the type systems of object-oriented programming languages by first providing a critique of the type systems of existing statically typed object-oriented programming languages. The reason for providing such a critique is that our goal is not only to describe existing programming languages, but also to use a deep understanding of the object-oriented concepts in order to design better object-oriented languages... we hope this chapter will give the reader a better insight into the overall goals of this work and provide motivation for the later work on extending the expressiveness of object-oriented languages. Posted to OOP by Ehud Lamm on 3/20/02; 3:19:04 AM Discuss

Daniel Friedman: A Poorman's 'Roll Your Own' Object System
Implementing OOP in Scheme. The exposition can perhaps be made clearer, but the ideas are worth thinking about. In a sense this is just another prototype implementation of classes and inheritance, but the construction is both pretty short and self contained. Posted to OOP by Ehud Lamm on 3/2/02; 12:54:28 PM Discuss (7 responses)

Java's new Considered Harmful

The author tries to make the case that the standard Java object allocation method (new) is broken. The premise is twofold: First, the new operator is tied to one specific heap allocation, at the exclusion of any other possible memory pools. Second, the new Operator is non-polymorphic in that it requires the call to be tied to a specific class - thus preventing the code from being reused for subclasses of the instantiated object. There is a difference between requesting an object and creating one. The first is an abstraction; it should be designed into a class and should be under the class's control. The second is a low-level implementation detail. Java's new keyword, the standard way to obtain objects, provides only the latter. Thus, most requests for objects end up being nonpolymorphic heap allocations, whether this is a good idea or not. In short, new should be considered harmful for the same reason that goto is considered harmful — although it is an indispensable low-level tool, it must be used with care or hidden behind abstractions. Although I think that new should be judiciously used, I don't think the author makes the case for a revised syntax. Not every design pattern (in this case Factory) needs to be a built in feature of the language. At some point in the code, somebody has to decide where and how a object of a specific class needs to be instantiated. Whether one puts it in-line, or hides it behind an abstraction, there's still a method that has to go about allocating the object. Posted to OOP by Chris Rathman on 3/2/02; 11:05:21 AM Discuss (5 responses)

Discovering Squeak

This project has grown out my frustration in trying to learn to Squeak. It is an example of the open source concept that work on a large collaborative project often happens when an individual "scratches his itch". The beginning of an online (wiki based!) book on Squeak. Newbies may enjoy reading this while learning. Experts may help make it happen. Posted to OOP by Ehud Lamm on 2/28/02; 4:19:29 AM Discuss (1 response)

rST - Remote Smalltalk

Framework for supporting distributed Squeak objects. The main goal of the project is transparency, so you don't need to change your objects to become remote. Another goal is to handle intermittence in the availability of the images, so PDA and Notebooks can interoperate in a distributed environment. Each object decides to pass "as copy" or "as reference", in the default implementation all objects pass "by reference" but Booleans, String, Character, Number and UndefinedObject (see implementors of #remoteType). This sounds cool. Transpatent distributed objects are the wave of the future... Posted to OOP by Ehud Lamm on 2/28/02; 4:16:24 AM Discuss (5 responses)

Turing Award to Ole-Johan Dahl and Kristen Nygaard

The Association for Computing Machinery (ACM) has presented the 2001 A.M. Turing Award, considered the "Nobel Prize of Computing," to Ole-Johan Dahl and Kristen Nygaard of Norway for their role in the invention of object-oriented programming, the most widely used programming model today.... The discrete event simulation language (Simula I) and general programming language (Simula 67) developed by Dahl and Nygaard at the Norwegian Computing Center in Oslo, Norway in the 1960's, led the way for software programmers to build software systems in layers of abstraction. With this approach, each layer of a system relies on a platform implemented by the lower layers. Posted to OOP by Ehud Lamm on 2/9/02; 12:36:53 AM Discuss

Squeak Modules

This is the place for growing documentation and everything else related to the Modules/Repositories/Packages system being added to Squeak 3.1 (2001-09-26) The version was in fact bumped to 3.3 more or less to mark the release of the modules code. Lots of interesting stuff. Delta Modules, for example, seem very much related to the notion of abstraction breaking I discussed in my Ada-Europe'2001 paper (full text requires S-V subscription). [This is related to ideas from generic programming, as I discuss in that paper. For example, Odersky's lectures at the GP summer school is titled OO anf Functional approaches to compositional programming] Check out the what to do next page. Posted to OOP by Ehud Lamm on 2/6/02; 1:51:29 PM Discuss (1 response)

Software Patterns Representation Languages
This page offers a collection of links and information of other resources about precise and formal specification languages for object oriented patterns, as well as tools supporting their application, recognition, and discovery. Looks like a rich resource. Posted to OOP by Ehud Lamm on 1/21/02; 12:20:22 PM Discuss

Subject-oriented programming @ IBM

Create extensions to, and configurations of, software Customize and integrate systems and reusable components Facilitate multi-team system development Permit decentralized development of classes Simplify code for many design patterns Subject-oriented programming is a program-composition technology that supports building object-oriented systems as compositions of subjects. A subject is a collection of classes or class fragments whose hierarchy models its domain in its own, subjective way. A subject may be a complete application in itself, or it may be an incomplete fragment that must be composed with other subjects to produce a complete application. Subject composition combines class hierarchies to produce new subjects that incorporate functionality from existing subjects. Subject-oriented programming thus supports building object-oriented systems as compositions of subjects, extending systems by composing them with new subjects, and integrating systems by composing them with one another (perhaps with "glue" or "adapter" subjects). The site includes some examples, and information about tools (e.g., Hyper/J). Posted to OOP by Ehud Lamm on 1/16/02; 4:27:37 AM Discuss (1 response)

Abstracting input sources
(via diveintomark) In the simplest case, a file-like object is any object with a read method with an optional size parameter, which returns a string. Nothing new here, but none the less an nice motivating discussion on dynamic binding and polymorphism. Posted to OOP by Ehud Lamm on 1/3/02; 12:35:50 PM Discuss

E - secure,distributed, pure OOP and p2p scripting language

(vai HtP) Marc Stiegler's draft tutorial book on E language programming, The E Language in a Walnut seems very readable, and informative. He writes: E is the best language introduced to date for developing distributed systems. As one quick example of its power, the E Promise Architecture ensures that deadlock cannot occur. E is the only sensible language introduced to date for secure distributed systems. All communication in E is strongly encrypted, transparently to the programmer. Capability-based security makes writing and auditing the security elements possible to an extent heretofore unachievable.... E is the first language ever introduced that is able to cope with multi-party partial-trust mobile code. "Mobile code" is just about anything executable on your computer that you get from somewhere else. For those familar with Ada: In Ada task communication and synchronization are interwined. The rendezvous between tasks synchronizes the two tasks, and then normal parameter passing happens. E uses the the opposite approach: the eventually operator sends a request, but doesn't require synchronization. This makes sense since, in E, we are thinking about distributed prograaming, and not about tasks running on the same computer. (Indeed, the Ada Distributed System Annex itself isn't based on the rendezvous mechanism). Even if you are not really interested in E, you may find the discussion of language underpinnings for capabilities interesting (you have to scroll down a bit; no direct link). It talks about language features that make security problematic. E is currently implemented on top of the JVM. Posted to OOP by Ehud Lamm on 12/31/01; 6:24:43 AM Discuss (4 responses)

So what do you think of cross-language inheritance?
I got this link from a message Dan posted to the discussion group. (I've been thinking of cross-language contracts recently. Maybe they can help.) Posted to OOP by Ehud Lamm on 12/26/01; 3:38:30 AM Discuss (6 responses)

LOOP: Formal methods for object-oriented systems

LOOP stands for Logic of Object-Oriented Programming. It is the name of a research project, and also the name of the tool that plays a central role in this project. The topic is formal methods for object-oriented languages. The aim is to specify and verify properties of classes in object-oriented languages, using proof tools like PVS and Isabelle. We indirectly mentioned this project, by linking to papers on Java verification, and on colagebras. Posted to OOP by Ehud Lamm on 12/25/01; 6:00:19 AM Discuss

Comparison of OO languages late-binding semantics
(via the LL workshop listserv) Tested languages : Ada95, C++, C#, CLOS, Dylan, Eiffel, Java, OCaml, Python, Smalltalk, Visual Basic (To be tested...Beta, and others if you want to contribute). and tested language interaction using 2 .NET languages: VisualBasic/C++, VisualBasic/C#, C++/VisualBasic, C++/C#, C#/VisualBasic, C#/C++ Posted to OOP by Ehud Lamm on 12/6/01; 4:24:39 AM Discuss

Design Principles Behind Smalltalk
This Squeak wiki page has tons of interesting links. Go and browse. Posted to OOP by Ehud Lamm on 12/1/01; 11:07:19 AM Discuss

Java Generics and Method Objects

In this article, I'll introduce you to the new Generics Specification (which came out of the Java Community Process) and then rebuild the command object framework using it. This won't actually change the performance of the application or add any new functionality. It will, however, add a substantial amount of compile-time type checking to the framework, thereby making the code easier to maintain and extend. Most of this article is a tutorial on the Java Generics Specification. Java generics were discussed here at length, and this article doesn't cover any new ground. Still, this seems like a decent tutorial. Posted to OOP by Ehud Lamm on 11/30/01; 1:00:53 PM Discuss

Designing Tapestry Mega-Components

Tapestry: Java Web Components is a powerful, flexible, open source framework for creating Web applications in Java. Tapestry builds on existing J2EE technologies to create an environment for robust, scalable, and highly dynamic Web applications. The framework was designed from the start to allow the creation of rich, reusable components. This article will explore the construction of one such component, the Palette, which exercises many of the advanced features of Tapestry. The article repeatedly talks about the power of components, but in fact these are not ordinary components. What we have is an entire set of languages, layered on top of each other (HTML and Javascript are, of course, languages themselves). That's why it is not surprising that Basic development took two days. Later, an additional day was spent reworking it to operate reasonably in Netscape Navigator 4, and then more time to adjust to Navigator 6. But now that the component exists, it is easier to use the Palette component than it would be to implement the other solutions. Posted to OOP by Ehud Lamm on 11/30/01; 12:49:53 PM Discuss (1 response)

C++ FAQ LITE

(via www.keithdevens.com) Well, sometimes you just need to understand the dark corners of C++... I like the anti-control freak approach to programming: sometimes it is just more sensible to put a comment saying the a class is final, than to use some coding trick to inhibit inheritance. Also check out the entries on reference and value semantics and pointers to member functions, a common C++ concern (let's all say closure together now..). Posted to OOP by Ehud Lamm on 11/30/01; 6:44:07 AM Discuss (4 responses)

C# From A Java Developer's Perspective

A comparison betwixt Java & C# over on Kuro5hin - pretty good rundown of the differences. Most developers, especially those with a background in C or C++, would probably agree that features like operator overloading, pointers, preprocessor directives, delegates and deterministic object cleanup make C# more expressive than Java in a number of cases. Similarly, Java developers who learn C# will be pleasantly surprised at features that are missing in Java that will seem glaring in their absence once one uses them in C#, such as boxing, enumerations and pass by reference. On the other hand the lack of checked exceptions, inner classes, cross platform portability or the fact that a class is not the smallest unit of distribution of code makes the choice of C# over Java not a clearcut case of choosing more language features without having to make any compromises. Personally I think of C# and Java as being pretty much the same language, with some feature rearrangement here and there. I don't see much in C# that is a significant advancement. The real differences are in the underlying VM's and libraries (API's), not in the languages. Posted to OOP by Chris Rathman on 11/19/01; 10:11:51 AM Discuss (2 responses)

Playing with Swiki

Swiki is a Squeak based Wiki. Like all Squeak based efforts the Swiki UI is beautiful, which is why I installed it and started looking at the source. I didn't really study the system yet, but I found quite a few things I liked. The way Swiki uses Smalltalk inheritance to categorize Wiki sites, and to control their attirbutes is very elegant. The Swiki browser is a nice demonstration of inheritance. I also like the flexible table driven design. It is basically based on XML metadata that tells Swiki how to fulfill different kinds of requests (more on this when I have more time). Not only do the XML files parameterize the system, they specify the required actions by pointing to files that contain Smalltalk code. Now this is what I call a dynamic language! I think the XML files are loaded into Smalltalk Dictionaries, which is also kind of nice (Dictionaries are part of what you get for free in ST), but this is really small potatoes compared to the overall design. I just started looking at Swiki this morning, so I apologize for any mistakes. I hope to say more about this nice piece of software, and how its design utilizes ST, in the future. Posted to OOP by Ehud Lamm on 11/14/01; 1:59:58 PM Discuss (4 responses)

Object-oriented programming and protected objects
A good discussion about integerating OOP and concurrency. The paper discusses proposals for integrating Ada's protected objects (~ monitors) and inheritance. All about the inheritance anomaly etc. There are some more recent papers about this issue, but they are not freely available. Posted to OOP by Ehud Lamm on 11/12/01; 1:44:54 AM Discuss

Implementing Dynamic Language Features in Java

This paper describes implementation strategies for structural conformance, wrapping, delegation, and mixins that do not rely on compile-time type information, do not impose the overhead of reflection on method calls, and do not require modifications to the Java runtime. Instead, the implementation strategies described in this paper rely on dynamic code generation facilities of Java to generate efficient "glue code" that can then be cached for later execution. Came across a reference to this paper on a discussion on JavaLobby about Reflection API Performance. Ok, so it's sort of a hack. But I suppose if you want to get truly dynamic behavior out of Java, it's the only path. Amounts to generating classes on the fly that do the delegation to the appropriate objects. If Sun ever really wants to help these kinds of efforts, the number one thing they could do is add a doesNotUnderstand: method to the method invocation that could be overidden by the classes. Posted to OOP by Chris Rathman on 10/24/01; 12:39:45 PM Discuss

Squeak ECOOP 2001 tutorial

Squeak, the open source Smalltalk system, is very much worth looking into, if you haven't done this already. This tutorial is a good way to start (we mentioned others here in the past). I like the direct manipulation morphic exercise (the worksheets, are in the big PDF file, right after the slides). This is something you can show VB fans... Posted to OOP by Ehud Lamm on 10/6/01; 1:00:57 PM Discuss (1 response)