Squeak-dev August 2002

squeak-dev@lists.squeakfoundation.org

175 participants
535 discussions

Design Patterns and Collection Classes
by Richard A. O'Keefe 29 Aug '02

29 Aug '02

"David Griswold" <David.Griswold(a)acm.org> wrote: So if there is any overall message here, it is: be very careful with code in classes like this, and show great restraint by making changes as minimal as possible. The code in Collection is simple, but not simple-minded. Don't underestimate the subtlety of why these simple-seeming methods are the way they are. In another context, Brian Foote and Joseph Yoder wrote [http://www.laputan.org/mud/mud.html; capitals are theirs and were links]: ... when you are prototyping a system, you are not usually concerned with how elegant or efficient your code is. You know that you will only use it to prove a concept. Once the prototype is done, the code will be thrown away and written properly. As the time nears to demonstrate the prototype, the temptation to load it with impressive but utterly inefficient realizations of the system's expected eventual functionality can be hard to resist. Sometimes, this strategy can be a bit too successful. ... Does this sound a bit like the history of Smalltalk? It should. A whole new language every two years. A research goal that was not "how do we build ideal collection classes" but "how do we take the idea of object orientation and build a language and system around it that can be understood ("Personal Mastery") and used in powerful ways, how can we develop a whole new approach to programming?" ... Time, or a lack thereof, is frequently the decisive force that drives programmers to write THROWAWAY CODE. Taking the time to write a proper, well thought out, well documented program might take more time than is available to solve a problem, or more time than the problem merits. Often, the programmer will make a frantic dash to construct a minimally functional program, all the while promising him- or herself that a better factored, more elegant version will follow thereafter. They may know full well that building a reusable system will make it easier to solve similar problems in the future, and that a more polished architecture would result in a system that was easier to maintain and extended. Quick-and-dirty coding is often reationalized as being a stopgap measure. All too often, time is never found for this foloow-up work. The code languishes, while the program flourishes. THEREFORE [and this is their recommendation], produce, by any means available, simple, expedient, disposable code that adequately addresses just the problem at hand. ... while this approach [that is, the approach used in a particular example, not throwaway code as such] is, in general, a lousy way to address this [particular example's] problem, it is perfectly satisfactory within the confines of the particular purpose for which [it] has ever actually been used. Such practical constraints are typical of THROWAWAY CODE, and are more often than not undocumented. For that matter, everything about THROWAWAY CODE is more often than not undocumented. When documentation exists, it is frequently not current, and often not accurate. Does this sound like #removeAll: and #addAll:? It should! ... [Two example] systems might be good candidates for RECONSTRUCTION, were the resources, interst, and audience present to justify such an undertaking. In the mean time, these [particular] systems, which are still sufficiently well suited to the particular tasks for which they were built, remain in service. Keeping them on the air takes far less energy than rewriting them. They continue to evolve, in a PIECEMEAL fashion, a little at a time. Doesn't this sound like _everything_ about Squeak? From the core classes to Morphic? Isn't piecemeal (community) improvement part of the _point_ of Squeak? So David Griswold claims that the Collection classes are subtle, simple but not simple-minded, and that the methods (including the ones I claim are broken) are the way they are for excellent reason and should not be altered without great [indeed, to my thinking, extreme] restraint, while I claim that the Collection classes are a "Ball of Mud" where most methods are the simplest thing that could possibly work, except they don't. Obviously, eyewitness testimony from the original developers could settle this. Except that it couldn't; it could only tell us how they remember what they thought they were doing. We need some more objective criterion to help us decide what kind of code we are dealing with here. If we are dealing with entire and perfect chrysolite, what we need is documentation. If we are dealing with mud, we need documentation AND repairs. So let's look away from #removeAll: and #addAll:. Let's even look away from #union:, #intersection:, and #difference:, enchanting though their perversity may be. ---------------------------------------------------------------- A Design Principle. ---------------------------------------------------------------- Every class should have a class invariant. It does not need to be expressed as code, but it needs to be thought about and written down. Initialisation methods have the obligation of setting up an object's state so that its class invariant is true. Other (externally accessible) methods get to assume that the invariant is true and have the obligation to ensure that it is still true when they complete. If you cannot rely on sufficient knowledge about the object's state at the beginning of a method, the only thing you can do to restore the invariant is reinitialise. If the invariant of a class depends on the state of a mutable object, and that object is accessible outside this class, then you DON'T have an invariant and you cannot expect your methods to work. So the design principle is: a class's invariant should depend only on the values of its instance variables and the states of such objects as are immutable or are not shared with other objects. ---------------------------------------------------------------- The Collection Classes ---------------------------------------------------------------- Do the collection classes heed this warning? Many of them do. OrderedCollection, for example, never hands out its array, and does not provide any non-private methods for changing its instance variables. (At least, by putting methods in the 'private' category it is warning "don't call these lest the heavens fall".) Set, for another example, depends on the exact state of its array, but never hands out access to that array. BUT it also depends on the state of the elements; it requires that the hash code of an element not change. Oddly enough, it _does_ provide a repair procedure that can be called. You could mutate the elements of a Set, taking care that the Set itself was not used while this was happening, and then invoke the #rehash method. Except that #rehash is private. With the exception of numbers and symbols, there are no immutable values that one might use as keys. There is no equivalent of OPAL's InvariantArray, for example. (I'm trying to write one and it's a nightmare. Array has so *many* methods that think it's OK to smash, even when they are making copies.) But what about Dictionary? Dictionary cannot make up its mind whether it's about Sets of Associations or keyed collections of values, and tries to be both. Considered as a keyed collection of values, a Dictionary's Associations are part of its private internal structure. Dictionary's invariant concerns the structure of its hash table, which depends on the state of these Associations. Yet it is perfectly happy to hand those Associations out to anyone who asks. Consider d := Dictionary new. d at: #red put: Color red. d associationsDo: [:each | each key: #green]. d inspect ==> (shows #green -> nil) d at: #green ==> (Error: key not found) d at: #red ==> (Error: key not found) Had Dictionary been designed with class invariants in mind, it could still have looked much the way it does now, but the Associations it hands out would be InvariantKeyAssociations, where Association subclass: #InvariantKeyAssociation instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Collections-Support' "private methods" pvtKey: k value: v key := k. value := v. "accessing methods" key: k self shouldNotImplement "class instance creation methods" key: k value: v ^self new pvtKey: k value: v Except that this won't work; practically the only time I ever really need 'pvt' methods is so that a class can initialise a new instance without the initialisation method being exposed to another class, but the 'pvt' machinery will not let you do this: "private messages may only be sent to self". If only there were a category of private messages that a class could send to 'self new'. So the method _really_ has to be called #privateKey:value: and we just have to _hope_ that no outsider will use it. So much for private methods. It's all very well to say that competent programmers wouldn't even _try_ to change the key of an association that came from a dictionary, but if there are two things that the last fifty years of programming and the recent history of the Internet have taught us, they are - EVERYONE makes mistakes - some people deliberately try to break other people's programs. Oh yes, what if no Association is changed, but a key is? Just like Set, Dictionary _could_ let you make a series of changes to keys (as long as no previously unequal keys became equal) and then repair the state of the dictionary using #rehash, _except_ that #rehash is a private method. (Which means you _can_ do this, but you shouldn't.) #rehash depends on a rather weaker invariant: it requires that keys still be non-nil and unequal, but it doesn't require that their values or hashes be unchanged. Is there another Collection class that exposes its internal structure? Yes, MappedCollection. MappedCollection collection: c map: m in effect constructs the composition of two tabulated functions: (MappedCollection collection: c map: m) at: index = c at: (m at: index) The base collection c and the map m are not copied when you do this. Indeed, that's the point. But it leads to some very odd consequences. For example, i ~= j and: [ (mc at: j) ~= 0 and: [ mc at: i put: 0. mc at: j = 0]] can come out true. For every other keyed collection, setting the element at one key doesn't alter any elements at other keys. So DON'T try to sort a MappedCollection! It's also the only Collection class I can find in Squeak 3.2 where (coll contents) is not the receiver but a copy with different properties. One of the nasty things about the fact that the collection and mapping are shared with unknown numbers of other objects is that foo: aCollection bar: aBlock |index value| index := aCollection size. value := aBlock value: (aCollection at: index). aCollection at: index put: value may fail, even though aBlock value: ... doesn't send any messages whatsoever to aCollection. How? aBlock could make the mapping smaller, or alter its last element so that it is no longer a valid key for the other collection, or could alter the other collection so that the key disappears, &c. Oh yes, imagine the fun when you do a := #(3 1 4 1) copy. m := MappedCollection collection: a map: a. m ==> a MappedCollection(4 3 1 3) m at: 2 put: 2. m ==> a MappedCollection(1 2 1 2) m at: 3 put: 3 m ==> a MappedCollection(1 2 3 4) a ==> #(2 1 4 3) MappedCollection *tacitly* assumes that the collection and mapping are different objects OR that neither will be changed, but it does not say this anywhere. At the very least the class comment for MappedCollection should be changed from I represent an access mechanism for a sequenceable collection re-ordering or filtering its elements. (which is quite untrue because it doesn't in the least depend on the collections being sequenceable) to I represent the composition of two collection. (MappedCollection collection: c map: m) at: index is always the same as c at: (map at: index). The collection and map could be any combination of sequenceable collections and dictionaries as long as the elements of m all are (and remain) acceptable keys for c. My instances are sequenceable precisely when their maps are sequenceable. If you plan to use #at:put: with one of my instances, the collection c and map m should be different objects. Note that the collection c and map m are NOT copied, but are shared. If you change them, the mapped collection you made from them will also change. Changes to the elements of the collection are normally safe; changes to the key space of the collection or the elements of the map may make the mapped collection invalid. Do not change the map while you are iterating over the map or the mapped collection. Hey, there's another oversight, found while writing that new class comment. There's a missing method: "in category 'testing'" isSequenceable ^map isSequenceable Alternatively, if the (otherwise pointless and unnecessary) restriction to sequenceable collections is to be preserved, then #setCollection:map: should be setCollection: aCollection map: aDictionary self assert: [aCollection isCollection]. self assert: [aDictionary isSequenceable]. domain := aCollection. map := aDictionary except that the names of the method parameters (which I have not changed) *strongly* suggest that the map should be allowed to be a dictionary, which is NOT sequenceable. But the instance creation method calls the very same parameter aSequenceableCollection. Whatever this code may be, it is not 'subtle'. It's confused and confusing. Are there any other collection classes that violate this design principle? Yes, there is one that doesn't so much violate it as cut its breast off and eat half of one of its kidneys: LinkedList. Most container libraries regard a linked list as a container for general objects, with the link nodes being part of the private structure of the list. From the outside, it should not matter whether the nodes are allocated one at a time, or in chunks (a good way to combine the flexibility of lists with the space efficiency of arrays is to have a linked collection of arrays; the well known "piece table" representation used in some editors is related to this). However, Smalltalk LinkedLists are very different: all their elements must be Link nodes. This makes them utterly unlike arrays; any number of arrays may refer to the same object as an element, and an array may include an object as element any number of times. Not so LinkedLists: each Link may be an element of at most one LinkedList, and then at most once. In other words, LinkedList does not encapsulate. Serious weirdness can result. Consider c1 add: c2 first. where c1 and c2 are *separate* collections sharing no objects at all before this message is sent. If c1 is any other kind of collection that can support #add:, this is fine. Now c1 and c2 have a common element. But if c1 and c2 are both LinkedLists, now a node is shared between the two lists. While #add: is defined to be #addLast:, it need not actually true that c2 first is now the last element of c1! (Because c2 might have had more than one element.) I could multiply examples of how easy it is to break LinkedLists without exploiting (initial) aliasing, but the main consequence is that Smalltalk programmers should never _ever_ use LinkedList, not even after making their own subclasses of Link. Arguably, LinkedList should be outside the Collection hierarchy. (As noted in an earlier message, LinkedList is amongst the SequenceableCollections, but does not support #at:, surely a defining characteristic of such collections.) Make no mistake: - I am not saying Smalltalk is unusable. - I am not saying the Collection classes are unusable. - I am not saying that the Smalltalk designers are culpable. What I _am_ saying is that the Smalltalk designers weren't _trying_ to produce highly polished code but were engaged in research of a completely different kind, so that they produced 'good enough for the immediate task' code which after 20-odd years outside the lab is overdue for an overhaul. The Collection classes are a means to an end, not Holy Writ, and mortals may dare to criticise and revise them.

6 5

Re: RE: GC behavior?
by Bob Arning 29 Aug '02

29 Aug '02

On Thu, 29 Aug 2002 06:11:15 -0400 "Stephen Pair" <spair(a)acm.org> wrote: >Is >there some way that this (that the VM keeps doing IGCs because of low >space as opposed to reaching the allocation threshold) could be >detected? Try changing the allocation threshold and see if that makes any difference. Here's a method I use: 'From Squeak3.2gamma of 15 January 2002 [latest update: #4743] on 29 August 2002 at 8:06:14 am'! !SystemDictionary methodsFor: 'miscellaneous' stamp: 'RAA 6/14/2002 14:41'! useLargerAllocationsFor: aBlock "increase the number of allocations between incremental GC's in hopes of gaining speed" | old answer | old _ self vmParameterAt: 5. self vmParameterAt: 5 put: 300000. answer _ aBlock value. self vmParameterAt: 5 put: old. ^answer! ! Cheeers, Bob

2 1

removeAll:
by richard＠simula.no 29 Aug '02

29 Aug '02

What I have learned from this discussion: - Few, if any, can present a complex logical argument without error or ambiguity. - The longer the presentation, the more error and ambiguity. - More are driven to respond to insult than to a resonable proposal. Even to perceived insult. - Richard A. O'Keefe is very good at presenting logical arguments and is a prodigious writer. - Important Smalltalk methods rely on the invariance of method arguments during execution but do not document or verify this assumption. - The semantics of these methods could be defined to make argument invariance the responsibility of the method implementation, rather than caller. - Documentation of either semantics is easy. It seems the ideal solution would not require callers of a method to know or care how the method is implemented. That means the burden of ensuring argument invariance falls on the method implementation. Ideally, again, we would perform no useless work. An argument is copied only when it is known that it will be modified. I wish I knew how to do that... Rich

1 0

GC behavior?
by Stephen Pair 29 Aug '02

29 Aug '02

Relating to the work I'm doing on the Persistence VM, I've encountered a perplexing performance issue relating to incremental GC. In my modified vm/image, which has no compact classes, I'm seeing an interesting performance degradation. Looking a "0 tinyBenchmarks" the number of bytecodes/sec has increased slightly (this is due to some improvements indirectly relating to the removal of compact classes I think)...but, the number of sends/sec has dropped from roughly 2 million to about 750k. Using MessageTally on Ian's CCodeGenerator benchmark, I see some interesting facts about incremental GCs. In the normal vm, I see 1503 IGCs taking 3,308 ms and 9% of the time. There are 150 tenures with 10 GCs/tenure. In the modified vm, I see 6339 IGCs taking 14,443 ms and 23% of the time. There are 173 tenures with 36 GCs/tenure. Both VMs seem show the same time (2ms) per GC...so I don't think having the extra class header has much of an impact on the marking performance. This would seem to indicate that more garbage is being created, but I have no idea how. I guess my question is, can anyone think of how removing compact classes (and having a class header on every object) would have this kind of impact on GC? I've been over the Interpreter changes time and again and can't find anything obvious. I'm thinking it must be something unrelated to the removal of compact classes (perhaps changing the hash to 14 bits is causing some un-anticipated side effect that results in creating more objects). - Stephen

2 2

Re: A new prospect for Squeak + GTK+
by yampa＠mindspring.com 29 Aug '02

29 Aug '02

On Wed, 28 Aug 2002 17:58:28 +0500 reic0024(a)d.umn.edu wrote: > wrote: > > I will look at this too, as it is already > fairly close to what I am doing with > > XML and BobsUI. Maybe this can be added on > later to BobsUI. > > Have you looked at the xmlspec stuff that can > be used to build both > Morphic and MVC GUIs? Yes, I started with that code. >Are you planning on > making a GUI builder that will > output whatever XML format that you'll be using > for your BobsUI work? > Yes. > I definately think it would be neat to, from > the same XML spec, be able > to have both OS-level "native" looking GTK+ > apps as well as > Squeak-native Morphic apps. :) With what I see in that web page, its probably too much to expect to see the same xml spec be able to open up either in Morphic or GTK. However, it may be possible to have the GUI builder be able to write out two different xml spec formats, one of them GTK. It might be possible to write them out to the same model object, so that a model can open a window in BobsUI or in GTK, but that would depend a lot on how the communication occurs between squeak and GTK.

2 1

Re: [BUG]Collection>>removeAll:
by David Griswold 29 Aug '02

29 Aug '02

"Richard A. O'Keefe" <ok(a)cs.otago.ac.nz> wrote: > "David Griswold" <David.Griswold(a)acm.org> wrote: > I suspect that some (Richard at least), are feeling > like myself and > other nay-sayers are simply being obstructionist about > a simple issue. > > There are two quite distinct "negative" reactions: > (A) Don't do anything *yet* until we understand what to do. > (B) Don't do anything, leave it the way it is. > > I've been seeing things that I can only understand as (B). What you are seeing is (C) Don't change Collection semantics unless a very good reason is shown. No one is just flatly saying "Don't do anything, leave it the way it is". I just don't think suggestions that we change the semantics of #removeAll: have met the "good reason" test. > But there is a very good reason for the kind of > critical discussion that > has been going on, and it is actually a good thing. > > Rational/critical debate is always a good thing. > > "If it was good enough for granpaw, it's good enough for me" > actually makes sense quite often, but ultimately it won't do. > > We are not talking about JoeBlowCornerOfTheSystem, > but the *Collection* class and protocol, arguably as > close as you can > get to the heart of Smalltalk. > > Yes, that's why it is so scary that the Collection classes > are so amazingly > fragile when you poke them. > > This class and protocol have withstood an enormous amount of use > in the real world, > > (1) That is, "it was good enough for granpaw". > (2) About Collection and its protocols, this isn't quite as true as it > seems, since Squeak has a large number of collections that are > not in the coloured books and don't seem to be in the commercial > Smalltalks whose manuals I've been able to check. Many of them > seem to break assumptions in the older classes. Squeak also has > a large number of additional methods. > > and even a very slight > change needs to be really, really thought about. > > Er, why should *THIS* change be subject to that stricture when so many > *other* changes have not been? I mean, seriously? > I jumped into the conversation only because it seemed to me that > the necessary "due diligence" wasn't being done. > > But why for *THIS* change, when so many changes have been made to the > Collection classes without anywhere near this much debate? > Why not this > level of resistance to all the other things that have gone into the > Collection classes? The other changes should have been subjected to this kind of discussion too. Just because slapdash programming exists does not justify more of it. > Let no-one mistake me. > I am in full agreement with careful design of core classes. > I am in full agreement that _every_ change requires design. > > HOWEVER, I do not think that a correction has to be held up to > extremely stringent standards (that no other part of Squeak > could meet) > in order to be useful or acceptable. > > I've made my points, but to be constructive and try to > move forward, > here is how I would reason about this problem and what > to do about it. > I'm laying it out in painful detail to show the kind of > restraint I > think is needed when dealing with important code like this. > > - it is clear that people do try to write (x removeAll: > x), and that it > doesn't do what they expect. This seems to happen > frequently enough > that it would be desirable to at least let people know when this > happens, so they can write their code a different way. > The currently > accepted valid ways to empty a collection are to either > create a new > collection (usually the fastest way) or say (x > removeAll: x copy). > > Well, no. There isn't any *polymorphic* way to create a new empty > collection, because for some very strange reason, there is no > *general* > #copyEmpty method in Collection. (I have suitable implementations for > #copyEmpty sitting in a change set waiting for resolution of > the Bag issue. > Maybe I should split that out.) > > And it really is very much an exaggeration to say that > "x removeAll: x copy" is an "accepted way" to empty a collection. > It is a way. It is a good way. But practically nobody knows > about it. > It's what people do when they burn their fingers on "x removeAll: x". > > - If we come up with a way to detect this case and > generate an error, > then the only remaining rationale for extending > removeAll: to support > the special case of the receiver as an argument would > be if it was > required by ANSI, or made the library or its > specification simpler and > cleaner, or fixed an actual bug. I believe that none > of these has been > demonstrated to be true. > > Oh COME ON. I have quoted the ANSI standard at length to demonstrate > that it *does* require the argument==receiver case to be supported. > I have also explained repeatedly not only _that_ the change makes the > specification simpler and cleaner, but _how_ it makes the > specification > simpler and cleaner. > > Rational/critical debate at least requires a rebuttal of these points, > not a flat denial that no demonstration was ever made. I've been trying to have a rational debate with you, but you seem to have a knack for treating anyone who doesn't agree with you as a dummy (e.g. "Oh COME ON"), which makes it pretty trying. I'll try to spell it out for you, but this is the last time I will try to explain to you why some people who aren't dummies don't agree with you about the ANSI standard: I don't think the ANSI standard says what you think it says. Just because it doesn't explicitly say that the receiver isn't allowed doesn't mean that the receiver *must* be allowed. I made a clear argument that all programs in Smalltalk (or in any imperative language for that matter) have a universal, *implied* constraint that you shouldn't change objects that are being used by something that assumes that they remain the same. This language-wide constraint clearly excludes (x removeAll: x), and the specification for removeAll: doesn't override that. Note that my argument about this implied constraint is not that the libraries have been designed that way, or that that's the way I think thing were meant etc., I'm saying this implied constraint is required in Smalltalk; you just can't get around it. It isn't stated explicitly because it isn't a design choice- there is simply no other reasonable general alternative in an imperative language like this, and programmers are expected to know it. Maybe it should be stated in the spec, but regardless of whether it is stated or not, this constraint is in force for the ANSI spec, because it *must* be. Programmers should read this additional constraint into all ANSI specifications, so that removeAll: has the implied language "the argument can be any collection that is invariant during the execution of this method". I don't *like* that, but it is necessary. Now, given the above view, changing removeAll: to work with the receiver as the argument is not a simplification, it is can be viewed as added complexity, because it adds a special exception to removeAll: (that is not there for the many other methods like this), that effectively says "for this message, you have the additional capability of passing in collections that are not invariant under this operation". That is not a simplification of the specification, because it requires additional generalization language, and makes removeAll: work differently than addAll: etc. Now, it appears you don't agree with this, but you can't say you haven't been rebutted. > So how would we detect the error? Richard has argued > for just putting > the check in. I say it belongs in an assertion, even > though it is a > very fast check, and here is why: every time a > programmer thinks of > some invariant like this that they want to check, they > make a little > 'cost' calculation in their head, and if the check is > going to have much > of a performance cost, they tend to not do the check. > > But how does this argue against an extremely fast check? > And how does it argue against a check THAT IS FASTER THAN AN ASSERT? I think assertions are the right way to go, but an assertion vs. a fast check in this case is no big deal to me in this case (as long as the check is not *required* by the message semantics), since the check is trivial and removeAll: is much slower anyway. The big deal is changing the semantics of removeAll:. If your fast check tries to handle this case and doesn't cause the programmer to be notified, that is what I think hasn't been justified. > Using assertions automatically for all of these kinds of checks > eases that difficult cost decision, which encourages people to > sprinkle these checks all over their code (a Good Thing). > > Except that programmers who look up what #assert: does > discover that it > is slow (block creation + message send). (The 3.2 browser makes it > very easy to check this. Type an assert: into some method, > and use the > rightmost button to select "bytecodes" instead of "source".) > > Lest I be misunderstood, I would be *delighted* if the compiler made > a special case of "self assert: -explicit block-" like it does for > ifTrue:. Then David Griswold's argument *would* be valid and > I *would* > be reasonably happy with "self assert: [aCollection ~~ self]." > > Just because this particular check happens to be very fast does > not make it a special case. > > The logic of this is "just because this is a special case doesn't mean > it is a special case." He has just argued that programmers > will put in > assert: because it is faster than a test, but is now arguing that > programmers will NOT put in a test that is (obviously) faster than an > assert:. What kind of mindless animals are these programmers? > > So I would recommend the following fixes: > > 1) Get the assertion mechanism working effectively and > efficiently in > the standard Squeak release. Make sure its cost in > development is > minimal, and its cost in production, zero. > > YES. YES. YES. > > 2) Just add "self assert: [ otherCollection ~~ self ]." > to the beginning > of removeAll:. > > Except that as someone else has argued, it doesn't actually > solve the problem. > > Very, very simple. (a Good Thing). It prevents this > whole issue from > being a problem, with no changing of the basic > Collection interface or > implementation required, and with no performance impact > in production > (Good Things). > > No, it does not solve the problem. > The problem is that > - #removeAll: fails to conform to the ANSI specification > - #removeAll: is hard to *think* about because of an > arbitrary restriction > - the restriction has nothing to do with the semantics of > the operation, > it is solely a consequence of a naive implementation. As I have said repeatedly, I don't think any of your alleged three problems are actually real problems. I think #removeAll: does conform to the ANSI spec, I think it is not an arbitrary restriction, but a common and universal one, I think the restriction has a lot to do with the semantics of the operation, and I don't think it is a consequence of a naive implementation- I think the implementation does the correct thing. > All it does is ensure that in likely cases involving existing > collection > classes the bug will not go unreported. > > Make no mistake, this suggestion would be a very definite improvement > over the present situation. Bugs that report themselves are > better than > bugs that quietly give wrong answers. > > But it is nothing more than a bandaid. The RIGHT answer is > to design the > interface so that it has as few exceptions as reasonably > possible and to > write the code so that it implements a clean specification. > > This applies throughout the collection classes, which are > badly in need > of an overhaul, not least some good documentation. > > Now, to the second, separate matter: is a new > #removeAll method needed? > > If (x removeAll: x) is not allowed to work, then yes. > There isn't any other polymorphic way to achieve what it does. > > I can see only one good reason for a #removeAll > message. That is that a > large, tenured collection might need it as a hook to > implement a more > efficient way of being emptied. > > More efficient than _what_? What has "large" or "tenured" > got to do with it? > > The main reason that I can think of is Smalltalk's dependency > mechanism. > If I have a changing collection which is being "watched" by > some receiver > (quite a reasonable thing to do) then creating a new empty collection > instead of emptying the old one would be the wrong thing to do. > > Another argument that might be made is > that people need a generally easy way of removing all > of a collection's > elements, but I don't buy that because most of the > time, they should > just create a new empty collection, which is usually > faster, so we don't > want to particularly encourage doing #removeAll anyway, > since it is > usually the slowest way to get the job done. > > Speed isn't my issue. Preserving identity so that the > Observer pattern > continues to work is my issue. > > However, the large collection argument is a good one, I think. > > The question then becomes, where does this method belong? One > could argue that code dealing with such large > collections almost always > knows a lot more about the collection than just that it > is a collection > that supports remove:, so adding efficient removeAll > methods to specific > collection classes could be done without adding it to > the Collection > protocol itself. > > I believe Goran's suggestion was that it should be implemented in each > class that introduces new structure. So it belongs in Set and Bag and > OrderedCollection and ... > > I have suggested that #removeAll: itself might profitably be > removed from > Collection on the grounds that the majority of descendants of > Collection > cannot support it. > > On the other hand, since removeAll is conceptually > built using remove:, > adding a default implementation to Collection doesn't > break any subclass > of collection, since it doesn't use any message other > than do: and > remove:. > > And most descendants of Collection do not and cannot support #remove:. > If that isn't a "code smell", what is? I personally agree that #remove:, add:, etc. don't belong in Collection itself. In Strongtalk I factored them out into the separate protocol Extensible, which OrderedCollections, Bags, etc. support. In Strongtalk, the Collection protocol is the true minimal protocol that all collections support. But in all other Smalltalks I've seen, they are in Collection, so that is a separate discussion. > So basically, I think this argument comes down to > weighing whether the > "large collection" argument is good enough to overcome > the drawback of > breaking existing classes that implement Collection > without inheriting > from it. > > I'm sorry, just what is being proposed that would break > existing classes? Changing the meaning of removeAll:. It breaks all existing classes that implement the Collection protocol or reimplement #removeAll:. > *LOTS* of methods have been added to Collection that are not > supported by > classes that used to be reasonably good Collection mimics. > > I myself tried to write a class (EnumerationWrapper) that > looked a lot like > Collection without inheriting from it, and it was a really painful job > because Collection has a LOT of methods and many of them are > difficult to > impossible to put in other classes. That is exactly why I think the Collection protocol should be minimal, especially in a system without mixins (which would allow people to never have to reimplement the whole protocol). I think what you are saying actually supports my point that Collection should only be changed rarely and reluctantly. If all those other methods weren't thrown in there, you would have had a lot easier time of it, and your code wouldn't break as often (as it will every time the Collection class semantics are changed). You asked me for examples of classes that would break. If the classes you wrote support remove, *your* code is a perfect example of the kind of code that will break. > I'm not drawing a conclusion here, just trying to delineate > the crux of the issue. I personally think removeAll > would be a nice > addition, but it would break some code out there, and > it's not used that > often (and shouldn't be), so I'm on the fence about it. > > Again, with the possible exception of code that deliberately causes a > DoesNotUnderstand, how would _adding_ a method to Collection > "break" any > other class? Can you give an actual example? I just gave the example above: any other class that implements Collection without inheriting from it, including your own class you mentioned above. > If such a method was added, in Collection it needs to > be something > really simple. You can do this safely and generally > without copying if > you write > removeAll > [ self isEmpty ] whileFalse: [ self > remove: self anElement ] > > which I have already proposed, except that instead of > inventing a new method, > I used the #anyOne method which is _already_ there in Collection. > In fact, it's the very first method in the 'accessing' category. Cool! It is obviously convergent evolution; I hadn't noticed that method- it does the same thing as my anElement. Which makes the code simpler. If you already proposed this algorithm, good. > Unfortunately, without an inlining compiler, anElement > is not very > efficient in Squeak right now, although with inlining > it could be more > efficient than copying. > > Returning one element could be more efficient than copying the whole > collection? Of course it could, but what does that tell us? > It already > is. And no, removing _all_ the elements this way could take quadratic > time (if, say, anyOne returned the last element of a sequence) and it > certainly wouldn't be a good way to remove elements from a Heap. > This is not to knock inlining, or native code generation either. > > So if there is any overall message here, it is: be very > careful with > code in classes like this, and show great restraint by > making changes as > minimal as possible. The code in Collection is simple, but not > simple-minded. Don't underestimate the subtlety of why these > simple-seeming methods are the way they are. > > Well no, the problem is precisely that #removeAll: and #addAll: *are* > simple-minded. The "set" operations #union:, #intersection:, and > #difference: appear to be a little more confused than that. > > By and large, MOST of the code in the Collection classes is > "The Simplest Thing That Could Possibly Work", > except that sometimes it doesn't. You may think it is simple-minded; I don't. You may think the code in Collection shouldn't place such a premium on simplicity; I do. That doesn't make *me* simple-minded. Cheers, Dave

2 1

Re: [GOODIE] invarAssn-raok
by Richard A. O'Keefe 29 Aug '02

29 Aug '02

I posted InvariantKeyAssocation, "a subclass of Association which can be safely used when the key must not be replaced." Tommy Thorn <thorn(a)meko.dk> wrote: 1) What exactly does it mean to replace the key? Suppose you do x := Association key: #foo value: 27. The basic operations now available are x value => 27 x value: 99 changes x, returns x. x value will now be 27 x key => #foo x key: #bar changes x, returns x. x key will now by bar. Basically all that InvariantKeyAssocation does is block this last message. I assume that it assumes the association itself as a mutable object Yes, they are. Always have been. where the key can be updated (which is not ok), whereas deleting a pair (k,v) and inserting a new (k',v) is ok? Right. This is a building block for a new version of Dictionary (NOT a change to Dictionary, a whole new class). However, I'm _really_ supposed to be writing exam questions, so it may be some time before I get to finish the rest of it, and I thought this chunk might be useful as it stands. 2) What is the advantage of InvariantKeyAssociation / when should it be preferred? Consider aDictionary associationsDo: [:eachAssociation | eachAssociation key: nil]. This doesn't actually make sense, but Squeak won't stop you doing it. InvariantKeyAssociations are associations with a key you can't change, so my new Dictionary-like class will be able to hand its associations out safe in the knowledge that which object the key _is_ can't be changed. The values can be changed, indeed that's one reason why #assocationsDo: is useful. But the values aren't used to structure the dictionary. The key objects may be mutated, but the ANSI Smalltalk standard says over and over again "don't do that", so I think we can expect people to know not to change the keys themselves. Note that it is possible to imagine an implementation of #associationsDo: in which changes to the keys were allowed and worked. Here's one: associationsDo: aBlock |deltas old| deltas := OrderedCollection new. super do: [:eachAssociation | old := eachAssociation key. aBlock value: eachAssocation. eachAssociation key ~= old ifTrue: [deltas addLast: {old. eachAssocation key. eachAssociation value}. eachAssociation key: old]]. deltas do: [:eachTriple | self remove: (eachTriple at: 1). (eachTriple at: 2) ifNotNil: [ self at: (eachTriple at: 2) put: (eachTriple at: 3)]. This lets aBlock change a key; it notes the change and puts the old key back so that the structural properties of the Dictionary are preserved while the #do: is happening. (No, I am NOT proposing that #associationsDo: be changed. Nor am I suggesting that it _should_ have been like this. I'm only trying to stave off the inevitable comments that any Smalltalk programmer should just _know_ as a universal constraint across all programming languages that it isn't going to work. Well, it could have.) We REALLY need better comments in Squeak. Dictionary>>associationsDo: just says "Evaluate aBlock for each of the receiver's elements (key/value associations)." It should say something like "Pass each of the receivers (key->value) Associations to aBlock in an unspecified order. aBlock may change the value of an Association, but should not change any key."

1 0

Re: [BUG]Collection>>removeAll:
by Richard A. O'Keefe 29 Aug '02

29 Aug '02

> Eh? You think BUG-compatibility is important? > Look, StarMorph new openInWorld _also_ doesn't work in VisualWorks; > does that mean we shouldn't let it work in Squeak? 1) The argument presupposes the conclusion that the behavior is a bug; many have argued persuasively that it is not; and The argument does not presuppose that conclusion. The argument is the continuation of several days more or less continuous typing arguing *in detail* and with reasons that is a bug. I think I am allowed to be consistent with myself. 2) Compatibility *is* a very important, albeit not overriding, consideration. We don't want to break programs between versions. Yeah, but you CAN'T be compatible with BOTH VW *and* IBM Smalltalk on this point. Because VW gets it wrong, and IBM Smalltalk gets it right. (At least in the case of OrderedCollections.) When you can't be compatible with everyone, why not be compatible with the one that works in more cases? > Introducing an assertion, which makes the implicit precondition > explicit > though, doesn't hurt compatibility. > > Yes it does. If (coll removeAll: coll) quietly succeeds in VW > but reports an error in Squeak, that is even *less* compatible than > making it produce the right answer. As at least one of the co-authors of the Smalltalk ANSI standard has already written in these letters, this is acceptable precisely because the case was not intended to be defined as you have argued, You've lost me. "We forgot to think about that" does NOT imply "This is acceptable". That just isn't how you read standards. You read standards AS THEY ARE. notwithstanding the interpretation you impose on the words. I haven't imposed anything on the words. I have let them speak for themselves. That's how you read a standard. As an undefined result, any behavior conforms to an undefined case But it *ISN'T* an undefined result. The return value is explicitly specified, but the effect on the receiver is clearly spelled out. It is the people who want to argue that there is some case in which the required behaviour need not be produced who have to find some explicit warrant for the exception. I don't see how anyone reading the ANSI text would dream of there being an exceptional case UNLESS they had read the implementation in Squeak first and thought that was more authoritative than the text of the standard. Even then, I have now shown that a small efficiency tweak to #removeIndex: in OrderedCollection will make the code *as it stands* produce the correct behaviour for OrderedCollection. The fact that the actual code of removeAll: *as it stands* can deliver the right answer when #removeindex: is changed in a way that does not in the least change compatibility with ANSI, comments, books, programmers' expectations, or any other outwardly visible behaviour, makes the claim that the bug is somehow allowed or required by the ANSI specification look very weak indeed. The bug is basically caused by the fact that #removeIndex: does on average twice as many moves as it needs to. When a bug results from an inefficiency in a private method, it is ridiculous to claim that it's somehow "right". If someone had added a new primitive resembling C's memmove() and made #removeIndex: call that instead of the one it does call (which more closely resembles memcpy()), purely in the interests of efficiency, the bug would have gone away (in the case of OrderedCollection) and we might never have known it was there. This is why David's proposal (trap as an error, by assertion or otherwise) seems to be the best heard to date thus far. Actually, I proposed it first.

1 0

Re: [BUG]Collection>>removeAll:
by Richard A. O'Keefe 29 Aug '02

29 Aug '02

"David Griswold" <David.Griswold(a)acm.org> wrote: I don't think the ANSI standard says what you think it says. I have quoted the verbatim text of the 1.9 draft. I have asked anyone with access to the final version to correct me. If anyone thinks that the ANSI standard does _not_ say what I said, could they possibly quote the verbatim text of what it _does_ say? Just because it doesn't explicitly say that the receiver isn't allowed doesn't mean that the receiver *must* be allowed. I used to be a regular reader (and poster) in comp.std.c. I also used to follow comp.std.fortran, and watched the Ada Interpretation process for that Ada standard for some time with considerable interest. People in those communities repeatedly made the point that it is what a standard actually *says* that counts, not what the standardisers *meant* to say, or what someone thinks the standard *ought* to mean. Unless the standard is inconsistent with itself, what the standard says stands. I made a clear argument that all programs in Smalltalk (or in any imperative language for that matter) have a universal, *implied* constraint that you shouldn't change objects that are being used by something that assumes that they remain the same. Yes, but you are presupposing that #removeAll: *does* assume that. In traditional logical terms, you are begging the argument. *IF* removeAll: is allowed to assume that its argument is not going to change, then at most it needs an assertion. But that is precisely what has to be established. There is nothing in the ANSI standard that would lead a careful reader to conclude that #removeAll: *is* allowed to assume that its argument is not changed. It is possible to read the specification as *forbidding* that assumption, that reading is consistent with the rest of the standard, and that reading is easily implementable. This language-wide constraint clearly excludes (x removeAll: x), Not at all. It would only exclude (x removeAll: x) *IF* #removeAll: were "something that assumes [it] remain[s] the same". We are agreed that the *implementation* in Squeak *does* make that assumption. The whole question, with respect to the standard, is whether the standard *allows* it to make that assumption, and you really cannot answer that question by assuming it. Now, if there were a presumption that method arguments were not changed, then your argument would be valid. Is there such a presumption? In one specific case there _is_ a no-change requirement: 5.3.1.1 = 5.3.1.9 hash 5.3.4.1 = 5.6.2.7 = 5.6.7.1 = 5.8.1.4 = 5.8.2.6 = Note that a collection that uses #= to discriminate objects may only reliably store objects whose hash values do not change while the objects are stored in the collection. There's something related: 5.3.1.6 copy Any operation that changes the state of the new object should not as a side effect change the state or behavior of the receiver. Similarly, any change to the receiver should not as a side-effect change the new object. However, except for noting that MappedCollection>>copy clearly violates this, it doesn't quite answer our question. Getting warmer: 5.7.7.2 add: newElement The equivalence of newElement with respect to other objects should not be changed while newElement is in the collection, as this would violate the invariant under which the element was placed within the collection. However, as I've already noticed in earlier messages, add: is an excellent example of a message which *doesn't* in general assume that its argument doesn't change: x := OrderedCollection new. x add: x. doesn't depend on #=, and Squeak allows it, and on my reading, doing this doesn't violate the ANSI specification. However, x := Set new. x add: x. *would* change the equality or otherwise of x with other objects, so the ANSI specification *does* rule that one out. I was hoping to demonstrate that x := Set new. x add: x. x includes: x doesn't work. I was then going to argue that this one is OK because the ANSI specification *does* forbid it, unlike x removeAll: x. Unfortunately, it fails for the wrong reason. When Set tries to compute x hash, it goes into an infinite loop. Similarly, x := OrderedCollection new. x add: x. y := Set with: x goes into an infinite loop. (Do NOT try this in an image you care about.) This raises the interesting question of what #hash should do with possibly cyclic structures, and if you think that's of academic interest, take a look at Morph some time. (The point is that Morphs have a cyclic structure, so that cyclic structures are not altogether alien to Squeak, not that #hash doesn't work on Morphs.) For safety, #hash might be implemented as hash ^self hashWithDepthBound: 3 or something like that, at at depth bound 0 it could just hash the class or species of the receiver. I certainly couldn't find anything in the ANSI specification warning against using #hash with cyclic structures, and since the hashWithDepthBound: implementation is not only possible but actually _used_ in some programming languages, we cannot assume that everyone will know about it without being told. Now there is something extremely relevant: 5.1.2.2 Parameter Specification Aliasing information (for example, whether a parameter is stored, or whether a returned value is new or returned state) is specified to avoid having implementors use defensive programming techniques which result in unnecessary object creation and copying, incurring a performance penalty. We differentiate between incidental aliasing and essential aliasing, both for parameters and for return values. Essential aliasing forms a critical part of the behavior of the interface, and as such it must be specified by the interface designer. Incidental aliasing should not be specified since it is a side effect of implementation choices, and is not fundamental to the specified functionality of the interface. Essential aliasing of parameters is described using a parameter aliasing attributes [captured, uncaptured, unspecified]. Oddly enough, one thing that does not seem to be considered here is cases where aliasing is prohibited. A literal reading of the standard (and remember, standards are _supposed_ to be read literally provided you can do so without inconsistency) would suggest that if aliasing is _not_ indicated for a parameter, then it is "incidental aliasing" and "is not fundamental to the specified functionality of the interface". That is, contrary to what David Griswold is saying, there is an EXPLICIT presumption in the ANSI standard that aliasing which is not mentioned is NOT FUNDAMENTAL TO THE SPECIFIED FUNCTIONALITY OF THE INTERFACE. To summarise, what have we found by scanning the ANSI (1.9 draft) standard? - We have found that it IS clearly spelled out that collection keys must not change their hash code or equality relation to other objects while they are in the collection. It is fair enough for collections not to worry about the possibility that this might happen, and it is fair enough to blame programmers for the consequences who do something that the standard says not to do. - We have NOT found any stated presumption that method parameters are not changed by a method. For another example that this cannot be true of Smalltalk in general, consider asSet ^self inject: Set new into: [:s :e | s add: e]. The first argument of #inject:into: is most definitely changed when we do this. I think this is a fine thing to do. David Griswold says that there is a universal presumption that this kind of thing won't happen. Do you think this would be such a bad way to implement #asSet that every Smalltalk programmer should _know_ not to do it? - On the contrary, we have found an explicit claim that any aliasing that is not explicitly mentioned is "NOT FUNDAMENTAL TO THE SPECIFIED FUNCTIONALITY OF THE INTERFACE." and the specification for removeAll: doesn't override that. It doesn't have to override anything. David Griswold is *RIGHT* that if something assumes that an object isn't changing, you shouldn't change it. However, there is no language-wide constraint that *every* method assumes that *every* parameter is not changing. What he needs is to find something in the specification of #removeAll: that says that *this* method makes or is entitled to make that assumption, and there isn't anything like that there. "The receiver never retains a reference to the parameter, directly or indirectly, as a result of this message." So let's look at the aliasing specification for #removeAll: Parameters oldElements <collection> uncaptured What does "uncaptured" mean? It means that The receiver never retains a reference to the parameter, directly or indirectly, as a result of this message. Does that prohibit (x removeAll: x)? No: with any of the working implementations I've suggested, x doesn't have any references to itself afterwards that it didn't have before. Note that my argument about this implied constraint is not that the libraries have been designed that way, or that that's the way I think thing were meant etc., I'm saying this implied constraint is required in Smalltalk; you just can't get around it. We AGREE that if a method assumes that some object doesn't change, then it shouldn't be changed. That has never been the point at issue. The point is whether *THIS* method is entitled to make that assumption. As far as I can tell, nobody would ever have expected this method to make that assumption were it not for the way it *happens* to be implemented. When you are arguing about whether the implementation is broken or not, you really cannot assume its correctness in your argument, that's the fallacy called question-begging. Programmers should read this additional constraint into all ANSI specifications, so that removeAll: has the implied language "the argument can be any collection that is invariant during the execution of this method". Why should they do that? It is possible to implement the specification exactly as written *without* the code making that assumption. This method of exegesis is precisely backwards. I am saying that the standard should be read like this: Try to take the text literally. If what it describes is consistent with the rest of the standard and describes something that can be implemented with known technology, do not add any extra assumptions. In particular, I refuse to insert extra caveats, exceptions, holes, and quirks into a specification simply on the grounds that a simplistic implementation might have trouble. In particular, the way the specification of #removeAll: is structured is *strongly* suggestive that this assumption is not to be made. (I am not saying that the ANSI authors intended this. I am only commenting on the way the text stands.) One obvious way to word the specification would have been to say "x removeAll: y has the same effect on x that y do: [:each | x remove: each] would have had." But that's not what the specification (in fact, the specifications; there are several copies which I have previously quoted in full) say. They do NOT talk about iterating over oldElements. They can very naturally be read as specifying a two-pass algorithm: 1. Determine what elements are to be removed. 2. Remove them. And that reading certainly requires no assumptions whatsoever about whether oldElements is changed or not. I don't *like* that, but it is necessary. I have read your messages with great care, but I have failed to recognise an argument for this position. We AGREE that *IF* #removeAll: assumes that its parameter doesn't change, then its parameter mustn't be changed. We agree that for *each* method that assumes that some parameter does not change, that parameter must not be changed. We agree that whenever the text of the ANSI specification is such that it is a reasonable inference that some parameter should not change, it should not be changed, and the standard should be so read. What we do not agree about is whether the specification of *this* method requires any such inference. Surely the fact that the specification CAN be implemented in many difference ways *without* depending on such an assumption means that the specification of *this* method does *not* require any such inference. Now, it appears you don't agree with this, but you can't say you haven't been rebutted. What I can say is that I have not been offered any rebuttal that doesn't beg the question. IF #removeAll: assumes its argument doesn't change, why then the simplistic implementation that assumes that argument doesn't change isn't broken. We agree. What we disagree about is whether the hypothesis of that conditional is true. I have given plenty of reason to believe it is false, and I am still waiting for an argument that doesn't just assume its own conclusion. I personally agree that #remove:, add:, etc. don't belong in Collection itself. In Strongtalk I factored them out into the separate protocol Extensible, which OrderedCollections, Bags, etc. support. In Strongtalk, the Collection protocol is the true minimal protocol that all collections support. That sounds wonderful. Strongtalk sounds better and better. But in all other Smalltalks I've seen, they are in Collection, so that is a separate discussion. Not exactly. It establishes that you are willing to improve the Collection classes far more drastically than most. Good on you. Now we know your resistance to #removeAll: is not a resistance to change in the Collection classes as such. > I'm sorry, just what is being proposed that would break > existing classes? Changing the meaning of removeAll:. It breaks all existing classes that implement the Collection protocol or reimplement #removeAll:. You have merely repeated the assertion. What I have proposed is that the implementation of #removeAll: in Squeak should be changed in such a way that - the result is consistent with the ANSI standard - NO invocation will change in any observable way EXCEPT when the existing code quietly produces nonsensical answers. - to rephrase that, ONLY the case where you say there isn't any defined result would be changed. So no working code could break. I have checked all the existing classes that implement the Collection protocol and I say it wouldn't break them. You say it would. As the implementor of StrongTalk, you are an extremely clued up person who is good at writing Smalltalk code. So show me *how* it would break something. Provide an example. Again, if a class reimplements #removeAll:, it wouldn't be calling the changed code, so its behaviour would not change. If something's behaviour is not changed, how exactly is it broken? (Oh, the reimplemented code might not conform to the full specification, but then it never did; that wouldn't be a new breakage.) That is exactly why I think the Collection protocol should be minimal, especially in a system without mixins (which would allow people to never have to reimplement the whole protocol). I think what you are saying actually supports my point that Collection should only be changed rarely and reluctantly. Oh, I agree. But that doesn't mean I refuse bug fixes! In fact, it's precisely _because_ I don't want the specification changed that I _do_ want the bug fix. You asked me for examples of classes that would break. If the classes you wrote support remove, *your* code is a perfect example of the kind of code that will break. No, they won't. With the change, there are no more calls to #remove: than without (except for the buggy case), and their arguments are identically the same objects. In fact, with the change, my code would work in more cases, the direct opposite of being broken. There is no change to what is removed from what involved. > Again, with the possible exception of code that deliberately causes a > DoesNotUnderstand, how would _adding_ a method to Collection > "break" any > other class? Can you give an actual example? I just gave the example above: any other class that implements Collection without inheriting from it, including your own class you mentioned above. That's not an example, it is an assertion that an example exists, without actually exhibiting. My own collection classes are most certainly NOT broken by the change we are interested in, and adding a #removeAll method of the form [self isEmpty] whileFalse: [self remove: self anyOne] certainly would not break them. #isEmpty, #anyOne, and #remove: were part of the collection protocol, so any of my collection classes either implement all of them, or are never going to implement #removeAll anyway. > By and large, MOST of the code in the Collection classes is > "The Simplest Thing That Could Possibly Work", > except that sometimes it doesn't. You may think it is simple-minded; I don't. You may think the code in Collection shouldn't place such a premium on simplicity; I do. That doesn't make *me* simple-minded. Nobody has ever suggested that you are simple-minded. I am not opposed to simple methods; I think they are great. I think "The Simplest Thing That Could Possibly Work" is excellent advice. However, I don't believe that "simple" is better than "working", and I don't believe that "simple to implement" is better than "simple to use". (That's the design philosophy that led to C.) Using the simplest thing that could possibly work is an excellent strategy right up to the point where you discover that it DOESN'T work. Then you do the next simplest thing. The Collection classes as we find them contain many excellent things, but are in many ways very obviously the result of high speed development. By this time, it may not be possible to make any of the more desirable restructurings (such as the ones I now learn have been done in StrongTalk) without breaking anything. However, such cleanups as we _can_ make without breaking existing code (like fixing the #removeAll: bug) _should_ be made.

1 0

OSProcess for Mac OSX
by Rob Whitfield 29 Aug '02

29 Aug '02

Does anyone know where I can get a working plugin library for OSProcess for Mac OSX?

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
54
Older →

Jump to page: