Squeak-dev January 2007

squeak-dev@lists.squeakfoundation.org

160 participants
184 discussions

Symbol>>capitalized?
by Bill Schwab 02 Jan '07

02 Jan '07

I would probably just send #asString to the symbols vs. adding the new method. I agree that returning an instance of the same class is the correct behavior. Bill Terry Raymond: RE: Symbol>>capitalized? I would not recommend this. Normally, one would expect that a transformation like #capitalized would return an object of the same class. It would make more sense to define #asCapitalizedString and change the code to use it. Terry Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

3 2

Re: How can we deal with Message rot?
by Bill Schwab 02 Jan '07

02 Jan '07

Ralph, I wish you much success. Your idea of defining behavior by tests is a good start. Good tests for Morphic will be hard to write, and there will obviously need to be a process for getting them (and any) tests accepted for inclusion in the official suite, which will need to accept additions, deletions, and edits over time. Beyond that, some things will need to break. Sometimes, it will be that a test fails when it should pass (overly aggressive assertions, etc.). In other areas (e.g. stream exhaustion), Squeak behaves very differently from other Smalltalks, and probably should be changed. I would further encourage you to draw an underscore in the sand at the same time. Modularization will involve some pain. When it's over, I would hope to see reasonable ANSI/cross-dialect compatibilty (including streams), and unrestricted use of underscores in source code and the compiler. Please note that the latter does not have to kill single-key assignment, which can be accomplished by optional editor behavior. I doubt there will ever be a better time to clean up loose ends. Bill Ralph Johnson wrote (much snipped): Part of splitting the image into components involves having "official" and "unofficial" components. The official components are the ones that the release team will update. We'll have tests for them and make sure that changes do not break them. There will be a way for you to get a component accepted as official, basically by providing a test suite and having it pass all the existing tests. This doesn't really answer your question of how to make a fundamental change to Morphic. Morphic is short on automated tests, so changes to Morphic are more likely to cause trouble even though they pass the tests than changes to kernel classes. But the idea is the same as for any other system. Write tests that show what you want to do, and then make the changes, continually checking that you don't break anything else. Because Morphic is undertested, you'll probably have to write some tests for Morphic to prove to yourself (and us) that you didn't break anything. These will be valuable beyond your particular changes. My goals as leader of the 3.10 release team are to modularize Squeak and to develop processes for making a release that will improve the quality of the software and make it easier to make a release. Improved testing will be a key part of this. I imagine that our first few attempts will show a lot of need for improvement, and that we will have to shift directions a few times until we come up with a good process. But these are the main things on my agenda. The final 3.10 release will have lots of improvements, including new packages, new tools, and new features. But for me, these will be icing on the cake, since my main goal is to figure out how to modularize Squeak without losing the advantages of an integrated image. Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

1 0

Re: Start with a short user story. ( e.g. kbd focus) (from refactoring
by Bill Schwab 02 Jan '07

02 Jan '07

Chris, What about the common scenario of writing software for users who are not going to change? It can manifest as avoidable training costs, matching user expectations to avoid support hassles, or simply not biting the hand that feeds us. Bill Chris Muller: Re: Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread) subbukk wrote: > Using mouse cursor to set focus makes sense only when accompanied by > buttons, as in click, drag, drop or scroll. Otherwise (like in typing > keys), mouse cursor cannot be relied upon to indicate intention on user's > part. The mouse could moved accidentally. I think of an accidental movement as "noise" in the communication-line between the user and computer. This is more an issue with the 43-year old mouse as an input device. A more fluid input device is needed. > When I am typing in large body > of text, I prefer to keep my hands on the keyboard near the home keys. Of course, me too. And remain at the home row to "point" too (as mentioned, courtesy of TrackPoint). So I essentially have an 87-button mouse and keyboard at my disposal, right at the home row. Far from perfect of course, but it also doesn't suffer the static of accidently moving. > I > want the focus to be around the text cursor; mouse cursor is irrelevant. > But for click, drag, drop or scroll, the mouse cursor indicates focus. > Text cursor is irrelevant. This combined 87-button mouse and keyboard into "one" input device is more a "higher-bandwidth" human-computer interface than the sum of the two individually because it adds many, many more combinations of short gestures available on the screen to direct the software (e.g., 87 per visible non-text widget instead of.. about 4). All of these many more "valid" gestures are within "easy reach" (one point, one key); but only if the underlying software is capable of leveraging this (e.g., mouseOverForFocus). I can see that the input device really matters, because "point, key" is a lot of switching back and forth with docking-station and mouse (which I never use). I'd like to point out one other unintended side-effect of this. Besides more productive, I have found it more "serene". Not because its been a more "efficient" way to direct the software, but because of the consistency with which direction occurs (e.g., point, key). Certainly, it takes getting accustomed to the other when you are used to one.. Cheers! Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

1 0

Symbol>>capitalized?
by Todd Blanchard 02 Jan '07

02 Jan '07

Squeak 3.7 ish - I've got this meta model that stores attribute names as symbols. I frequently derive labels from the attribute names and this often ends up calling #capitalized on the symbol. I generally figure any string manipulation on a symbol results in a string but Symbol>>capitalized is implemented as capitalized ^self asString capitalized asSymbol I found this while watching the process browser running a lengthy script in the background and found about 80% of time was spent in WeakSet scanFor: I did a search of the image and couldn't find a single instance of sending capitalized to a symbol where the caller was going to use it as a symbol rather than a string. So, in the name of performance, I vote to nuke this method or change it to just return a string.

6 6

Jump to page: