From leavens@cs.iastate.edu Wed Sep 18 18:44:51 2002 Date: Wed, 18 Sep 2002 18:35:13 -0500 (CDT) From: Gary T. Leavens To: Brian Patterson Cc: Gary Leavens Subject: Re: A short SmallTalk ponderance Brian, On Wed, 18 Sep 2002, Brian Patterson wrote: > Hmmm, inspected Smalltalk and discovered that System Dictionary has > trouble with string keys (it only works with symbols e.g. > #glTupleColl). So now I have several copies of 'glTupleColl' around > that I can't get rid of in Smalltalk but I can manipulatet #glTupleColl > just fine. Thanks! Ah yes, symbols, of course. To fix your image, I would file out all of the code you have changed, and then start fresh with the original image; and file your code back in. Another thing is to roll back (or forward from the initial image) using the change set operations. -- Gary T. Leavens Department of Computer Science, Iowa State University 229 Atanasoff Hall, Ames, Iowa 50011-1041 USA http://www.cs.iastate.edu/~leavens phone: +1-515-294-1580 ------------------------------------------------------------------- From leavens@cs.iastate.edu Wed Sep 18 22:35:25 2002 Date: Wed, 18 Sep 2002 19:17:07 -0500 (CDT) From: Gary T. Leavens To: Computer Science 541 , Satish Kumar Vemula , Tongjie Chen , Xiaoyang Gu , Xiaoyang Gu Cc: George Ushakov , Gary Leavens Subject: Notes from 541 discussion about methods of the class Tuple for HW2 Hi, At the end of the Com S 541 discussion today, we talked about the specification of the class Tuple. We thought tuples should be immutable (although I wonder now if that's really necessary), and that they should be a subclass of OrderedCollection. We thought they should have the following methods (see corresponding methods in other OrderedCollection classes): Tuple subclass of: OrderedCollection "class methods" new with: anObject with: anObject with: anObject with: anObject with: anObject with: anObject withAll: anOrderedCollection "instance methods" do: aBlock at: anInteger (and other methods needed to define an OrderedCollection) classes The code for the method "classes" should be (we think, haven't tested this...) classes "Return a tuple of the classes of this tuple" ^self collect: [ :e | e class ] At the end there was some debate about whether we need an instance method like the perform: methods of Object (see Goldberg and Robson p. 244). It's necessary to distinguish, we think, the execution of a method on the tuple data structure (the methods from the list above) from running a generic function on a tuple. It seems thus that there needs to be another method, say callMultimethodNamed: selector that looks up the selector in the global TupleMethodTable, which maps pairs of a tuple of classes and a selector to the code for a multimethod. But for HW2, problem 1, let's say that this method isn't required. It will be for later parts of the homework. -- Gary T. Leavens Department of Computer Science, Iowa State University 229 Atanasoff Hall, Ames, Iowa 50011-1041 USA http://www.cs.iastate.edu/~leavens phone: +1-515-294-1580 --------------------------------------------------------- From leavens@larch.cs.iastate.edu Mon Sep 23 21:40:15 2002 Date: Mon, 23 Sep 2002 21:38:51 -0500 (CDT) From: Gary T. Leavens To: Becca Wemhoff Cc: Georgiy A Ushakov Subject: Re: Tuple class Becca, On Mon, 23 Sep 2002, Becca Wemhoff wrote: > OK, I've just heard that we're *not* supposed to be making this > a subclass of OrderedCollection but of Sequenceable Collection. > Do you know which it is? It's very frustrating since I'm not in > the loop... This is a bit of a misunderstanding. I originally thought that tuples should have indexed instance variables. If you want to do that, then there is no reason to inherit from OrderedCollection, which has its own instance variable which is an array. So I changed my code to inherit from SequenceableCollection instead. George and I worked this out during our meeting at 2pm, and I've literally not had time to mention this in email before that, but George has probably mentioned this to people. Anyway, I appreciate and thank you for your question. I do now think that inheriting from SequenceableCollection, and having indexed instance variables is a tiny bit more efficient. But it is perfectly fine to inherit from OrderedCollection, and so you don't need to change anything. We aren't really much concerned with the efficiency issues anyway. > Is there parsing code of yours that we're supposed to somehow use? It's still going into infinite loops... and so is hard to debug. I'm working on it... For now, test by building tuples by hand. Sorry for the delay on this. -- Gary T. Leavens Department of Computer Science, Iowa State University 229 Atanasoff Hall, Ames, Iowa 50011-1041 USA http://www.cs.iastate.edu/~leavens phone: +1-515-294-1580 ---------------------------------------------------------- From leavens@cs.iastate.edu Thu Oct 3 16:38:18 2002 Date: Thu, 3 Oct 2002 15:14:03 -0500 (CDT) From: Gary T. Leavens To: Becca Wemhoff Cc: Gary Leavens Subject: Re: Meeting outlines? Becca, On Thu, 3 Oct 2002, Becca Wemhoff wrote: > Though I think I'm the only one looking at them , are you > going to update the meeting outline directory with the most > recent lectures (exception handling, and so forth)? They are there. The recent ones are in /home/course/cs541/public/meeting-outlines/java.txt or from the "Java's design" link on the course syllabus web page, or directly from http://www.cs.iastate.edu/~leavens/ComS541/meeting-outlines/java.txt Let me know if that doesn't work for you (or if I fail to update in the future). I am not following these exactly because sometimes the class discussion (which is good) is more free flowing, but most of the ideas are there, and I'm trying to stay somewhat close to this to make sure I don't leave things out. -- Gary T. Leavens Department of Computer Science, Iowa State University 229 Atanasoff Hall, Ames, Iowa 50011-1041 USA http://www.cs.iastate.edu/~leavens phone: +1-515-294-1580 --------------------------------------------------------- From leavens@cs.iastate.edu Wed Oct 9 10:22:47 2002 Date: Wed, 9 Oct 2002 10:22:25 -0500 (CDT) From: Gary T. Leavens To: Neeraj Khanolkar Cc: Gary Leavens , George Ushakov Subject: Re: Java Array contravariance Hi Neeraj, On Wed, 9 Oct 2002, Neeraj Khanolkar wrote: > I was thinking about the way Java compiler allows Array store > contraviance, although it is caught at run time. > > In your example, where ColorPoint is a subclasss of Point : > > Point[] a; > a = new ColorPoint[] > a[0] = new ColorPoint(); > a[1] = new Point(); > > This compiles fine, but the third line throws a ArrayStoreException as > you said in class it would. > > I was thinking as to why the Java designers would do this. One reason that > I can think of is: > > The static type of "a" is Array of Point objects. Yes. > Since we dynamically > make "a" point to a new Array of ColorPoint objects it is not possible for > the compiler to detect this. "Not possible" is a bit strong, but the Java type system does not record that information. > OfCourse in the above example it seems easy > for the compiler to detect it but in general it would not. I guess it > would depend on how far down we can push the line on the easter egg. Exactly. > Also I think that we can actually safely defer the runtime exception to > casting time. That is we could allow the storage of Point objects in the > array, but throw a ClassCastException when we try to downcast "a" to an > Array of ColorPoint objects. The casting operation for the array could > simply check that each object stored is co-variant with the downcast type, > else throw an exception. No, there shouldn't be a class cast error because a really is an array of ColorPoint objects. > Since "a" is of static type Point, the user will be forced to downCast at > some time if he/she wishes to treat it as ColorPoint array.(which in fact > is its dynamic type) Yes, that's right. > Something tells me that this deferral would be a bad idea, but I cant put > my finger on it. The problem really comes when you have an alias to "a" which is of type ColorPoint[]. Consider: Point[] a; ColorPoint[] b; b = new ColorPoint[3]; b[0] = new ColorPoint(3, 4, Color.RED); b[1] = new ColorPoint(5, 4, Color.BLUE); a = b; // legal since ColorPoint[] <: Point[] a[2] = new Point(); // throws ArrayStoreException b[2].getColor(); // this is why the line above can't work We'll discuss it in discussion section more today. -- Gary T. Leavens Department of Computer Science, Iowa State University 229 Atanasoff Hall, Ames, Iowa 50011-1041 USA http://www.cs.iastate.edu/~leavens phone: +1-515-294-1580 --------------------------------------------------------------