Senior Staff Writer/Assistant Development Editor for the Technique. More info to come eventually.
Notes to self:
Arguments to a button
Standard file menu fix
Terse guide to squeak
Squeak file i/o
predictability: it fails to do action associated with buttons,
familiarity: buttons are never used as text labels,
responsiveness: Something should happen within a reasonable amount of time when a button is clicked but nothing happens in this case.
For this discussion, I read "A Comparative Study of Language Support for Generic Programming," by Ronald Garcia, Jaakko Jaervi, Andrew Lumsdaine, Jeremy Siek, and Jeremiah Willcock of the Open Systems Lab of Indiana University Bloomington. This paper is available through the ACM Digital Library (http://doi.acm.org/10.1145/949305.949317
) and was presented at the Conference on Object Oriented Programming Systems Languages and Applications in 2003.
The article compares support in six programming languages, four of them object-oriented, for generic programming, or, as defined in  (and reproduced in the article), "a sub-discipline of computer science that deals with finding abstract representations of efficient algorithms, data structures, and other software concepts, and with their systematic organization." The languages compared are ML, C++, Haskell, Eiffel, Java and C#. Of these, ML and Haskell are not strictly speaking object-oriented, though they do support several common features of object-oriented languages, such as polymorphism. The article evaluates each language's support for generic programming by implementing a generic graph library that is a subset of the Boost Graph Library, in all six. It then evaluates the ease of implementation and discusses the issues encountered in each language.
The authors conclude that no one language has truly flawless support for generic programming. They praise C++ for the flexibility of its function and class template features, but they point out that much of what the other languages accomplish with features C++ is forced to leave to documentation. Such compromises are highlighted in the remaining five languages as well. They also point out that generics serve a far smaller role in most object-oriented languages than in functional or procedural ones, saying, "Object-oriented programming techniques remain the primary mechanism for building abstractions in these languages." The overall conclusion is summed up in the authors' "Appeal to Language Designers": "Conscious consideration of support for flexible generics can improve the ability of these languages to express modular and reusable program components." It is this goal which would undoubtedly ease the burden on programmers.
In his discussion, Brian Smith stated, "Programming practices changed from a completely top-down design that read more like a book to a design that allowed for more encapsulation and better structure by being able to split up and reuse code." While it is difficult to take issue with his statement, the authors of my article suggest that modern languages are still not quite where they need to be to enable code reuse with the flexibility and quality that modern programmers demand.
 M. Jazayeri, R. Loos, D. Musser, and A. Stepanov. Generic Programming. In Report of the Dagstuhl Seminar on Generic Programming, Schloss Dagstuhl, Germany, Apr. 1998.
 J. Siek, L.-Q. Lee, and A. Lumsdaine. The Boost Graph Library: User Guide and Reference Manual. Addison-Wesley, 2002.
The information in the below discussion is based on the Wikipedia entries for the respective subjects it describes.
1. The three categories of design patterns outlined in the so-called "Gang of Four" book are all distinct in purpose and implementation.
The creational design patterns all relate to the building of objects: more efficient methods for creating classes that best fit the programmer's need. These define tasks such as creating many interchangeable but different objects (factory pattern), creating an object that is limited to only a single instance (singleton pattern), etc.
The structural patterns are intended to help with the building up of individual objects into complex systems, easing the creation of extensive user interfaces. They allow for improved interaction between your objects and delineate methods for integrating objects into a cohesive whole. Examples include the container pattern, in which objects are created for the sole purpose of holding other objects and which includes such common data structures as stacks and queues, and the adapter pattern, which formats data contained in one object into a form that is acceptable for another.
Behavioral patterns are used to implement object-to-object communication, increasing flexibility and simplifying the management of programmatic data flow. The event listener design pattern, which provides a better alternative to polling for user input handling is one example; the iterator design pattern, which allows for more efficient traversal of many data structures such as linked lists, is another.
2. I believe the iterator pattern is an interesting one because it has easily visible advantages over the most common traversal alternative, indexing. These advantages may include better performance with data structures that do not have efficient random data access, such as linked lists, the ability to safely modify the contents of a data structure on the fly, and improvements in code reusability and abstraction with regard to the specific data structure used behind the scenes of a process. I have used this in the past when dealing with Linked Lists in Java, and found the third advantage I mentioned to be rather significant. It enabled me to change between two different data structures without modifying any of the accessor code that was used to traverse them.
1. I had a Smalltalk issue that plagued me for several hours when I was working on Milestone 1. Whenever I tried to assign a variable, like so:
| foo bar |
bar := 1
foo := BookMorph new
...hitting Do It (Alt+D) resulted in an error message:
| foo bar |
bar := 1
foo Nothing more expected ->:= BookMorph new
The problem arose as a result of me not being familiar with Smalltalk syntax... I became very confused on whether a period was in fact necessary to end a line of code. (Yes, it is.
) Now, normally you wouldn't have such a problem, as most languages are very consistent about this sort of thing. But in Smalltalk, it seems the final line of code in a method not only does not REQUIRE a period, but specifically wants it to not be there – whenever I accepted the changes to a method (Alt+S), the period vanished. I definitely disliked this "feature," as it made saving changes in the middle of a method, then coming back to pick up where I left off rather frustrating because I kept forgetting to put a period at the end of the previously-final line.
A few things helped me overcome the problem:
- Getting a clue and putting a period after every line except the final one and the variable declarations.
- Using the 'color print' option in the System Browser to enable syntax highlighting, which automatically formatted the code and made it quite obvious if I was missing a period somewhere. The Color Print option is a dropdown on the right of the System Browser window, which says 'code' by default.
In any case, if you've successfully completed Milestone 1, you've probably learned to avoid this error.
2. I found the following two postings useful:
- File browser by Fiznik Shpuza - Fiznik's discussion posting is tremendously useful, as there are quite a few disparate and annoyingly undocumented ways to select files within squeak. His directions on using FileList2 were helpful, as they finally explained how I could filter files by type. There is just one caveat to Fiznik's post: The method call he pasted doesn't actually return the path as a string, but the file stream itself. This tripped me up until I printed the value to the Transcript.
- Arguments to a button by Ryan Nigro - Ryan's comments on passing arguments to a method called by a button were illuminating, as Squeak handles this in a rather counterintuitive way. The fact that 'arguments:' expects an array is somewhat confusing, though not entirely unexpected.
|Good job. This is the kind of post I had in mind for Discussion 3. The reason this is happening is that pretty printing removes the last period. Smalltalk doesn't actually care about the last period. It is perfectly valid Smalltalk syntax to leave it in. When you have pretty printing on, it "fixes" spacing and removes the last period. If you were to turn pretty printing off, your final period would stay. —Jeff Rick|
From Midterm #1 Review - Spring 2004
: Design Critique:
What is wrong with the following and how do you fix it? [Fixes in cyan
- We decided to have one shape class and have a type attribute which can be "Circle", "Rectangle", "Triagle". We have to case on the type to figure out what to draw. Later we need to case on the type again to output the postscript.
This is a pretty terrible idea from the perspective of further extending your code. What will happen if you suddenly decide you want to also have a "Pentagon"? You have to update every case statement you ever used. The proper solution would have been to have classes Circle, Rectangle and Triangle inherit from class Shape. This way you would be able to add additional classes without having to update 50,000 case statements.
- Boxes need to use a pen so we had Box inherit from Pen.
What does a box really have in common with a pen? The answer is "not a whole lot." The relationship between a box and a pen should be "has-a" rather than "is-a" one. A box should have a pen, not be a pen. A box also has plenty of functions a pen should not. Should you be able to resize a pen? Should you be able to draw inside a pen? Both of these are logical things you may want to do to a box, but not so logical when applied to a pen.
- We got lots of coding done because we were able to copy code to many different classes.
Congratulations! But hey, I just found a bug in one of the methods that you've pasted into 25 different classes. Have fun fixing it in all of them. Aside from that obvious caveat, this is also bad from an object-oriented perspective. If you need to copy more than a few lines of code, you should seriously consider if you ought not be inheriting the class you're copying code from, or using an instance of that class directly.
- We really only needed one "main" class and a couple of helper classes.
The concept of a "main" method and "helper" methods – just extended to classes in this case – is straight out of your C programming class. And if there's one thing C is not, it's object-oriented. Squeak, on the other hand, is, so your classes should be small, logical noun-based blocks. There should not be one "godly" class that controls your whole program; rather, your "objects" should work together in a roughly equal fashion.
- We call the class that edits the image part of the slide "EditBackground".
Naming conventions are important, and naming ANY class "EditBackground" is a bad idea. This one is particularly bad because it's not even terribly descriptive; nothing says the "image" is necessarily in the background. In any case, a key paradigm of Object Oriented Design is that your objects should function as nouns. In OOP, it's not "Dig," it's "Shovel" – and the names must reflect the paradigm. "EditBackground" explicitly defines a task. A name like "ImageEditor" would be far, far better.
a) What is a virtual machine?
A virtual machine is essentially a self-contained system that allows the execution of code that does not necessarily pertain to the real system it's running on; thus, it isolates the code it runs from the native hardware.
b) List three pros and three cons of virtual machines versus natively-compiled languages such as C.
- Portability; that is, write once, run anywhere -> no system-specific recompilation
- Memory management: The virtual machine can manage memory for all of the programs that use it, so no malloc, etc.
- Security: Because the code is isolated from the actual hardware, a malicious program may be able to do Very Bad Things to the VM but will not be able to get access to the actual system.
- Speed: Running code on a VM is inherently slower than natively compiled system code because it adds an extra layer to the execution.
- Power: Access to the native system allows a programmer to take advantage of system operations a VM may not allow access to.
- Resource use: Running your program on top of a virtual machine uses system resources that could otherwise be consumed by your program directly.