From leavens@larch.cs.iastate.edu Wed Aug 28 16:19:19 2002 Date: Wed, 28 Aug 2002 15:50:14 -0500 (CDT) From: Gary T. Leavens To: Becca Wemhoff Subject: Re: 541 Homework 1 Becca, On Wed, 28 Aug 2002, Becca Wemhoff wrote: > Is there a reason Homework 1 is titled Homework 3? Did we get > a time-warp, and I somehow missed HW1 and HW2? My mistake, thanks for catching that. > Is there recitation section today? I know you addressed this > in lecture, but brain was fuzz at the time... None today, we'll start next week. -- 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 Thu Aug 29 16:41:33 2002 Date: Thu, 29 Aug 2002 16:05:48 -0500 (CDT) From: Gary T. Leavens To: yaping@iastate.edu Subject: Re: CS541: squeak window Yaping, On Thu, 29 Aug 2002 yaping@iastate.edu wrote: > I'm just wondering what we should do if we want to get the squeak window via > remote login to CS machine. So far I got 'null display' if I telnet or ssh to > popeye or other CS machine. The simpliest is to just run squeak on the machine you are on. However, if you can't do that, then you have to have X windows running on the remote machine, and export the environment's DISPLAY variable properly. Like (in tcsh) % setenv DISPLAY titus.cs.iastate.edu:0 % ssh foo foo% squeak If you use ssh I think that works. Come up to my office if it's not working... -- 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 Sat Aug 31 10:55:11 2002 Date: Sat, 31 Aug 2002 10:54:28 -0500 (CDT) From: Gary T. Leavens To: Satyadev Nandakumar Cc: Gary Leavens Subject: Re: Squeak - Packages Satyadev, On Sat, 31 Aug 2002, Satyadev Nandakumar wrote: > I found out that the convention of naming projects with hyphen in them > actually is used in classifying them into packages. > > For example, all categories with name 'Kernel-*' go into package > 'Kernel' which can be seen using the package browser. > > I am not sure whether this has any implication, though ... That's cool. > P.S. Do we have a mailing list for the course? I feel that if it is > there, it might be useful for archiving some tips that people dig up, and > for discussing common bugs in programming. Yes, there is a mailing list for the course. I am also archiving emails (like this one) in the q_and_a.txt file accessible from the course web page. I'm happy to add things there. -- 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 Sun Sep 1 17:59:12 2002 Date: Sun, 1 Sep 2002 17:58:25 -0500 (CDT) From: Gary T. Leavens To: Brian Patterson Cc: Gary Leavens Subject: Re: Homework problem order? Brain, On Sun, 1 Sep 2002, Brian Patterson wrote: > Hi, I'm working on the homework for Thursday and it looks a lot like #3 > should be done before #2. After all, I can't think of a way to test > moving disks from one tower to another without the HanoiTower class. > So I'm going to do #3 then #2 but wanted to check as to whether there's > a particular reason not to do this. I think you're making too much out of problem 2. A HanoiMove is simply a *record* of moving a disk, not the actual movement of a disk. So you should easily be able to test problem 2 without having done problem 3. The HanoiTower class and the HanoiMove class are essentially independent of each other. So that's why I asked for 2 before 3. Good question. > Also, for the Q & A part of the website, could you put a row of > "------"s or something between the e-mails so that the e-mails you > reply to are seperated somehow. Thanks! I'm not sure how to do that, maybe if I put a row of these at the end of each email... -- 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 Mon Sep 2 19:26:26 2002 Date: Mon, 2 Sep 2002 19:25:33 -0500 (CDT) From: Gary T. Leavens To: Xiaoyang Gu Cc: gushakov@cs.iastate.edu, Gary Leavens Subject: Re: BlockClosure Jeff, On Mon, 2 Sep 2002, Xiaoyang Gu wrote: > Got it. > It seems the Lessons are not synchronized with the ClassLibrary. > In the current ClassLibrary, message value:value:value: is also defined. Thanks, I'm glad tht you figured that out. > ----- Original Message ----- > From: Xiaoyang Gu > To: leavens@cs.iastate.edu ; gushakov@cs.iastate.edu > Sent: Monday, 02 September, 2002 3:09 PM > Subject: BlockClosure > > > Hi, > The definitions of value: and value:value: are quoted from VisualWorks. > And the example in the lesson was changed to have three arguments for the block. > According to the comments in the method definitions, it seems that the modified > program should have failed. But it didn't. Just want to know why. > > Thank you! > > Jeff > xiaoyang@cs.iastate.edu > > value: arg > "Evaluate the block represented by the receiver. Fail if the block > expects other than one argument." > > > ^self valueWithArguments: (Array with: arg) > > value: arg1 value: arg2 > "Evaluate the block represented by the receiver. Fail if the block > expects other than two arguments." > > > ^self valueWithArguments: (Array with: arg1 with: arg2) > > > | adderBlock | > adderBlock := [ :first :second :third| > ( first + second + third) printString ]. > MyTranscript > show: (adderBlock value: 1 value: 9 value: 101); > cr . -- 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 4 15:48:28 2002 Date: Wed, 4 Sep 2002 15:47:58 -0500 (CDT) From: Gary T. Leavens To: Satyadev Nandakumar Cc: Gary Leavens Subject: Re: Squeak - making code safe Satadyev, On Wed, 4 Sep 2002, Satyadev Nandakumar wrote: > I do not know whether the following suggestion is an abominable one: > > To ensure that a variable passed into a piece of code is the expected type > [in order to avoid runtime errors], we can create an object of the > expected type and perform a query like so: > > anInteger class = 123455 class > > and check the Boolean result. > > Do you see any bad effects of doing so? Well there are some potential problems with doing this. First of all, you don't really need to guard against unwanted arguments in the code written for our class. You can write the past that you wrote as anInteger class = Integer which is a bit simpler, however this also shows that you're not allowing subclasses of that class to be used as arguments. So a better way to code this would be as follows: anInteger isKindOf: Integer More importantly, the notion of "class" is different than the notion of a "type" that is appropriate for Smalltalk. The notion of "type" should be based on protocol of an object, i.e. the messages that it responds to. Objects in different and unrelated classes can respond to the same protocol. There's no particular reason to limit the arguments of a method to elements of some particular class, as long as you can get the information out of the objects that are the arguments and manipulate them appropriately. You can test this using respondsTo:, e.g., anInteger respondsTo: #+ My advice is not to worry about this issue yet, although it's an interesting one that we will, I hope consider later. -- 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 Wed Sep 4 21:29:15 2002 Date: Tue, 3 Sep 2002 22:35:21 -0500 (CDT) From: Gary T. Leavens To: Computer Science 541 , Tongjie Chen Subject: show: for the Transcript, Blocks (Smalltalk) Hi, In class today, I was a bit confused about how to work with the Transcript. Sorry about that. It's often more convenient to use the `show:' message than the other messages (`nextPutAll:', `endEntry') that we were using. The definition of the `show:' message is as follows (in TranscriptStream): show: anObject "TextCollector compatibility" self nextPutAll: anObject asString; endEntry This is a good example of a convenience method, and also demonstrates the cascading message syntax. If you haven't seen closures before (e.g., `lambda' in Scheme or LISP, `\' in Hashell, `fun' in ML), the idea of a block may be somewhat confusing. This message is to try to explain one way to think about what a block does. (For those who have seen it before, we're going to use the beta rule from the lambda calculus.) Let's consider 1 argument blocks first. The simplest way to understand a block with one argument is to substitute the value of the actual argument for the formal parameter of the block. This is called the beta rule and is a reasonable approximation to the true semantics of blocks. For example, we may calculate the value of sending a 1-argument block the `value:' message as follows [ :x | x + 2 ] value: 3 = 3 + 2 = 5 A slightly more accurate way of conceiving the execution of blocks takes into account that the formal parameter is actually a local variable of the block's body. This is called the "environment model". In the environment model, you think of `[ :x | x + 2 ]' as a (unnamed) procedure that takes 1 argument, called `x', with body `x+2' (or `return x+2' for C fans). The passing of actual parameters to formals is model by bindings in the new environment. For example, the expression [ :x | x + 2 ] value: 3 creates a new environment in which the formal parameter variable `x' is bound to the value of the actual parameter, 3, and then runs the expression `x + 2' in that environment, so that when we look up the `x' during the evaluation of the expression `x + 2', we get 3. Therefore, as long as we don't assign to the formal parameter during the execution of the block's body, the execution is exactly the same as described by the beta rule. Another calculation may help: [ :y | (y + 2) printOn: Transcript. y ] value: 4 = (4 + 2) printOn: Transcript. 4 = "6 printed, then" 4 However, the above calculation does not show the details of the environment model. To do this, and to handle side effects like the above example, it's helpful to introduce more notation. Let `Effect(exp,env)' stand for the effect of expression `exp' in the environment `env'. We write environments (in ASCII) as `{ x |-> 3}', meaning the function that binds `x' to 3. The result of Effect is a pair containing a value and a new environment. For example Effect(y := 2, {y |-> 4}) = (2, {y |-> 2}). To formalize the treatment of environments, we also introduce two other pieces of notation. The notation `(val,env) - v', where (val,env) is a pair of a value and an environment is the pair (val,env2), where env2 is the same as env, except that it is undefined on `v'. The notation f + {x |-> y} means the function g such that g(x) = y, and for w not equal to x, g(w) = f(w). So we can calculate, for example: Effect([ :z | i := z + 1. z ] value: 3, {i |-> 2}) = Effect(i := z + 1. z, {i |-> 2} + {z |-> 3}) - z = Effect(i := z + 1. z, {i |-> 2, z |-> 3}) - z = Effect(z, {i |-> 4, z |-> 3}) - z = Effect(3, {i |-> 4, z |-> 3}) - z = Effect(3, {i |-> 4}) So in general, the meaning of a block with one argument is as follows: Effect([ :fm1 | body] value: act1, env) = Effect(body, env0 + {fml |-> v}) - fml where Effect(act1,env) = (v, env0) In simple cases, where the evaluation of the actual printer, act1, does not have any side effects, env = env0, and we have Effect([ :fm1 | body] value: act1, env) = Effect(body, env + {fml |-> v}) - fml where Effect(act1,env) = (v, env) In words, evaluate the body in an environment where the formal is bound to the actual, and return the result (together with any side effects on the environment). We could treat side-effects to the store similarly, but this would really get us into denotational semantics... Briefly, the meaning of a zero argument block is as follows Effect([ body ] value, env) = Effect([ :fresh | body] value: nil, env) where fresh is a variable that does not occur either in body or in the domain of env. Finally, the meaning of a n>1 argument block can be expressed in terms of the meaning of an n-1 argument block as follows: Effect([ :v1 :v2 ... :vn |body ] value: arg1 ... value: argn, env) = Effect(([ :v1 | [ :v2 ... :vn | body]] value: arg1) value: arg2 ... value: argn, env) I'll let you puzzle that out for yourself; or just try it 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 Thu Sep 5 18:45:02 2002 Date: Thu, 5 Sep 2002 18:30:31 -0500 (CDT) From: Gary T. Leavens To: Neeraj Khanolkar Cc: Gary Leavens Subject: Re: Protocol based checking - not. Neeraj, On Thu, 5 Sep 2002, Neeraj Khanolkar wrote: > This may probably be completely wrong in which case please excuse me > for wasting your time, but I can think of one reason why Smalltalk > compilers dont (or cannot) do protocol based, compile time "type checking" > for actual parameters to methods. > > Since the argument type is left unspecified I could easily construct > class that seems to obey the same protocol i.e have the same selectors as > some other class. However the arguments for those selectors could have > different type. In fact we could continue this saying that the arguments > also obey the same protocol but their selectors in turn use different > types for arguments. > > I think it's impossible to check all the way down the line, if all > the selectors match along with their argument protocols. (halting > problem?). No I think this is possible. I think the book @Book{Palsberg-Schwartzbach94, Key = "Palsberg \& Schwartzbach", Author = "Jens Palsberg and Michael I. Schwartzbach", Title = "Object-Oriented Type Systems", Publisher = "John Wiley and sons", Year = 1994, Annote = "72 reference." } presents an algorithm for doing this (in O(n^3) time). Eventually it reaches a fixed point, because there are only a finite number of methods and message sends in a given program (or Smalltalk image). Check it out from the book cited above, or read one of the following for your paper in 541: @Article{Palsberg96, key = {Palsberg}, author = {Jens Palsberg}, title = "Type Inference for Objects", journal = ACMCS, volume = 28, number = 2, pages = "358-359", month = Jun, year = 1996, annote = "8 references." } @Article{Palsberg-Schwartzbach90b, Key = "Palsberg \& Schwartzbach", Author = "Jens Palsberg and Michael I. Schwartzbach", Title = "Type Substitution for Object-Oriented Programming", Journal = SIGPLAN, Year = 1990, Volume = 25, Number = 10, Month = Oct, Pages = "151-160", Note = "{\em OOPSLA ECOOP '90 Proceedings}, N. Meyrowitz (editor).", Annote = "31 references." } @InCollection{Agesen-Palsberg-Schwartzbach93, Key="Agesen \& Palsberg \& Schwartzbach", Author="Ole Agesen and Jens Palsberg and Michael I. Schwartzbach", Title="Type Inference of SELF: Analysis of Objects with Dynamic and Multiple Inheritence", Series=LNCS, Publisher="Springer-Verlag", Address=NY, Editor="Oscar M. Nierstrasz", Number=707, Note="ECOOP '93 - Object-Oriented Programming 7th European Conference, Germany, July 1993. Proceedings", Pages="247-267", Annote="15 references" } -- 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 Sat Sep 7 14:23:55 2002 Date: Sat, 7 Sep 2002 14:23:26 -0500 (CDT) From: Gary T. Leavens To: Brian Patterson Cc: Gary Leavens Subject: Re: Strange stream inheritence Brian, On Sat, 7 Sep 2002, Brian Patterson wrote: > Hi, I thought I understood inheritance but I guess I'm still confused. > Consider the following lines of code: > myColl _ Collection new. > myMoves _ HanoiMoveStream on:myColl. > > Now, myMoves _ HanoiMoveStream new. results in an error (written as a > Stream class function) that I must use on: or with: to initialize a > Stream. However, when I look for on: and with: methods in the Stream, > Object, or ProtoObject, I find nothing. It's seems very odd to me that > the Stream class would require me to use a method that isn't defined in > that class so I'm very confused about what's going on here. I could > define on: and with: myself I suppose but that still begs the question > of how instances of the Stream class itself are created. It looks like most of the interesting Stream classes inherit the class method on: from PositionableStream. Stream itself is an abstract class, and so doesn't allow objects to be created directly, in part because they cause this error in the new method. You have to either redefine the class method "new" in HanoiStream's class or define on: some some other class method for HanoiStream to allow objects to be created. Does that help? -- 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 Sun Sep 8 13:21:30 2002 Date: Sun, 8 Sep 2002 13:21:04 -0500 (CDT) From: Gary T. Leavens To: Brian Patterson Cc: Gary Leavens Subject: Re: "Introduction to Literature" handout on the web? Brian, On Sun, 8 Sep 2002, Brian Patterson wrote: > Hi, just starting to work on problems 9 and 10 but I've misplaced my > copy of the "Introduction to Literature" handout your gave us on the > first day. Is there a copy of it up on the web site somewhere? Thanks! Sorry about that, it wasn't available on the course web page previously. I've made it available from the course resources web page. You can also directly download it from the following URL: ftp://ftp.cs.iastate.edu/pub/techreports/TR93-01/TR.ps.gz -- 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 Sun Sep 8 17:59:48 2002 Date: Sun, 8 Sep 2002 17:50:35 -0500 (CDT) From: Gary T. Leavens To: Brian Patterson Cc: Gary Leavens Subject: Re: Quick verification on #7 Brian, On Sun, 8 Sep 2002, Brian Patterson wrote: > Hi, sorry for all the e-mails ... No problem. > but I just want to check that, for the > BinaryRelation class, we should be able to handle keys (the first > element) being related to multiple values (the second element). That > is, {(a,b),(a,c),(d,e)} is possible and at:a would return > {(a,b),(a,c)}. Yes you should be able to handle keys being related to multiple values. That example seems right to me. -- 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 Sun Sep 8 18:00:39 2002 Date: Sun, 8 Sep 2002 17:53:05 -0500 (CDT) From: Gary T. Leavens To: Becca Wemhoff Cc: Gary Leavens Subject: Re: reference [LB98] Becca, On Sun, 8 Sep 2002, Becca Wemhoff wrote: > Gary, > > In your introduction to the literature, reference [LB98] refers > to Sheng Liang and Gilad Bracha: "Ownership Types for Flexible > Alias Protection". That article is actually authored by Daev Clarke, > John Porter, and James Noble and appears on pp. 48-64. > > Liang and Bracha's article is "Dynamic Class Loading in the Java > Virtual Machine" on pages 36-44. From the citation in your paper, I > think this is the artitle title you intended... Thanks, I'll try to fix that next time I update the paper, which doesn't unfortunately look like it will be any time really soon... -- 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 9 19:00:15 2002 Date: Mon, 9 Sep 2002 18:59:35 -0500 (CDT) From: Gary T. Leavens To: Jon Mathews Subject: Re: hw1 questions for 541 Jon, On Mon, 9 Sep 2002, Jon Mathews wrote: > > After talking to George, I think I should ask you a few questions. > > Re: #6 > 1. The recursive solution wasn't forthcoming (although it probably should have > been), so I referred to a web page for some help. I commented and included the > url next to those lines of code. Is this acceptable, or did you mean for us to > suffer through the solution ourselves? I'd prefer that you suffer through it yourself, but doing that and citing the web page is okay, as noted in the course grading policy. Thanks. > 2. I implemented the HanoiMoveStream as a subclass of ReadStream. It computes > everything at the creation of the object, which is potentially expensive. I > also did not implement next as it was inherited correctly. Is this an > acceptable solution? It's okay to compute the moves eagerly, before they are needed. However, I think to be a subclass of ReadStream you should have to implement "next"; I don't see why you aren't able to do that. > Re: #8 > 3. If we choose not to store (key, key) and (value, value) in the reflexive set, > how do we properly implement do:? > > For example, suppose I have the pairs (a, b) and (b, c). When I pass > associations to aBlock I would implicitly generate (a, a) and (b, b) for the > first pair, and (b, b) and (c, c) for the second pair. Note that (b, b) is > generated twice. The only way I can think to avoid this is to generate the full > set before passing them to aBlock. However, at this point we've lost the space > efficiency and runtime is suffering as well, which misses the point. I believe > the other methods can be implemented correctly if BinaryRelation is correct. You could keep a set of the elements for which you have generated reflexive pairs as a local variable of "do:". That wouldn't be too much space and would be fairly efficient. > Re: #9 > 4. Can we assume that two Graphs are equal even if the windows are not? No, I think that you should consider 2 Graphs equals only if their windows are also equal. -- 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 Mon Sep 9 23:43:23 2002 Date: Mon, 9 Sep 2002 23:43:02 -0500 (CDT) From: Gary T. Leavens To: Becca Wemhoff Cc: Gary Leavens Subject: Re: Bibles of our industry Becca, On Mon, 9 Sep 2002, Becca Wemhoff wrote: > I had heard about "Design Patterns" before from a Java mailing list: > > Thomas E. Davis stated "the bibles of our industry." These are the > four books that all programmers should have in their library. I had > forgotten about the list until you mentioned it. > > 1. "Design Patterns" (Erich Gamma, Richard Helm, Ralph Johnson, > John Vlissides, Grady Boocha) > -- "Patterns simplify your job by helping you avoid the pitfalls of > memory limitations via object sharing" > Also: "Pattern Hatching: Design Patterns Applied" > -- Learn how the patterns evolved > 2. "Refactoring: Improving the Design of Existing Code" (Martin Fowler, > Kent Beck, John Brant, William Opdyke, Don Roberts) > -- offers options to starting over > 3. "Antipatterns: Refactoring Software, Architectures, and Projects in > Crisis" (William J. Brown, Raphael C. Malveau, William H. Brown, > Hays W. McCormick II, Thomas J. Mowbray) > -- catalogs common errors in planning and mismanagement and postulates > way to dig yourself out of the abyss > 4. "Extreme Programming Explained: Embrace Change" (Kent Beck) > -- "Communication, simplicity, feedback, and courage" I haven't read 2 and 3 (although I own 2, Clyde has it...), but 1 and 4 I have read, and they are very good. -- 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 Tue Sep 10 21:33:51 2002 Date: Tue, 10 Sep 2002 21:24:57 -0500 (CDT) From: Gary T. Leavens To: Neeraj Khanolkar Subject: Re: "Implements" keyword in Java Neeraj, On Tue, 10 Sep 2002, Neeraj Khanolkar wrote: > I'm sorry for jumping the gun and asking a Java language design > question; but your answer to my last email leads me to question the > need for a "implements" keyword in Java. > > If an O(n power 3) algorithm exists to check the protocol of the actual > parameter vis a vis the formal, then why does Java insist that classes tag > themselves with the "implements " keyword. > > Why can the compiler not check the protocol to make sure it is compatible > with that required by the interface, whenever that class is used as a > parameter where the formal is declared to be of some interface type? No apology necessary. That's a very good question. This is the classic distinction between by-name (declared) type relationships and structural (inferred) type relationships. Several people have suggested (although not any that I can recall in print), that Java would be better off with a structural type system. That has advantages for separate development: I can design a type that works with all objects that obey a certain protocol, and your objects can work with it, even if you and I don't know each other and never saw each other's code. This seems to be a good thing for component designs. However, the Java designers worked from (an intuitive?) understanding of software engineering concerns to argue against structural type checking. They saw the problem as being that you could get some false matches. That is, there might be two types with methods that have the same name and parameters but which are semantically quite different. A classic funny example: both graphic artifacts and cowboys can do "void draw()". More seriously, you wouldn't want to have meters and miles be confused, even though they are both units of length and probably have the same protocol. It would be interesting to take a Smalltalk system and try this algorithm out and to see what kinds of problems one finds, where, say types are not behavioral subtypes. William Cook had an article about this, which you might like to read: @Article{Cook92, Key = "Cook", Author = "W. R. Cook", Title = "Interfaces and Specifications for the {Smalltalk-80} Collection Classes", Journal = SIGPLAN, Month = Oct, Year = 1992, Volume = 27, Number = 10, Pages = "1-15", Note = "{\em OOPSLA '92 Proceedings}, Andreas Paepcke (editor).", Annote = "21 references." } Various people have designed langauges where it's possible for the programmer to decide whether to compare types by name or structurally. Modula-3 is a good example. You might want to try to imagine how they could give the programmer the choice before looking at the solution in Modula-3. -- 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 11 09:01:15 2002 Date: Wed, 11 Sep 2002 09:00:57 -0500 (CDT) From: Gary T. Leavens To: Satish Kumar Vemula Cc: George Ushakov , Gary Leavens Subject: Re: cs541 question Hi Satish, On Wed, 11 Sep 2002, Satish Kumar Vemula wrote: > Suppose a class inherits from a base class. Then, how fair is it on > part of the designer to not guarantee the behaviour of the class when > the users send messages defined in the base class to this class object. > Assuming that the messages in the child class are complete in the sense that > they allow all reasonable semantics of the class. Good question... > This question came, as I am looking at BinaryRelation and > ReflexiveRelation. I thought of a way of implementing the relation > interface (relate:to:, do: and at:) efficiently. This approach makes the > BinaryRelation class to extend from Set class. But the whole class > behaviour becomes undefined if the user of this class tries to access the > corresponding Set messages(like includes:, findElementsOrNil etc.). Overriding > these Set messages to make it compatible with Set messages, adds a lot of > burden to this class. Yes, then that would say you shouldn't make BinaryRelation a subclass of Set, but instead a subclass of Collection that includes a field containing a Set. However, findElementsOrNil in Set is not a public method (it's in the private category). > What is the right way of doing it. Do we need to assume that the user > is going to use only the messages exquisitely provided by the derived > classes. Yes, for purposes of 541 homework you can do that, because BinaryRelation's specification doesn't say anything about the messages of Set that aren't part of the Collection protocol, it should be okay to ignore them. In real life, I think this would be more of a problem unless you have a type system that enforces that, or some specification language that lets clients know exactly what the prototcol they can count on from BinaryRelations is. -- 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 Fri Sep 13 00:39:53 2002 Date: Fri, 13 Sep 2002 00:38:43 -0500 (CDT) From: Gary T. Leavens To: Neeraj Khanolkar Subject: Re: instruction and data distinction Neeraj, On Fri, 13 Sep 2002, Neeraj Khanolkar wrote: > On Thu, 12 Sep 2002, Gary T. Leavens wrote: > > Hi Gary, > I'm sorry but I still don't follow, could you please elaborate > the lines below: > > > Then we can change the value of a field by replacing the method that > > returns the field's value. The method that sets the field's value > > does its work by replacing this getter method. Have a look at (one of) the following papers: @InCollection{Abadi-Cardelli94, Key = "Abadi \& Cardelli", Author = {Mart\'{\i}n Abadi and Luca Cardelli}, Title = "A Theory of Primitive Objects --- Untyped and First-Order Systems", BookTitle = "Theoretical Aspects of Computer Software", Publisher = "Springer-Verlag", Year = 1994, Editor = "Masami Hagiya and John C. Mitchell", Series = LNCS, Volume = 789, Pages = "296-320", Month = Apr, Annote = "19 references." } @InProceedings{Abadi-Cardelli95b, Key = "Abadi \& Cardelli", author = "M. Abadi and L. Cardelli", title = "An imperative object calculus", editor = "P. D. Mosses and M. Nielsen and M. I. Schwartzbach", series = LNCS, booktitle = "TAPSOFT'95: Theory and Practice of Software Development", publisher = "Springer-Verlag", number = 915, year = 1995, month = May, pages = "471-485", annote = "26 references." } @Article{Abadi-Cardelli95c, Key = "Abadi \& Cardelli", author = "M. Abadi and L. Cardelli", title = "An imperative object calculus", journal = "Theory and Practice of Object Systems", volume = 1, number = 3, year = 1995, pages = "151-166" } @Book{Abadi-Cardelli96, author = "Mart\'{\i}n Abadi and Luca Cardelli", title = "A Theory of Objects", publisher = "Springer-Verlag", year = 1996, key = "Abadi \& Cardelli", series = "Monographs in Computer Science", address = NY, annote = "128 references." } -- 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 --------------------------------------------------------