Squeak-dev May 2003

squeak-dev@lists.squeakfoundation.org

204 participants
710 discussions

Re: KCP feedback (ii)
by Daniel Vainsencher 05 May '03

05 May '03

What I am saying is that class extensions aren't just packagable - they are a way to fix (some) dependency problems. For example - you could say that compiler is not part of the kernel, since we could imagine a small embedded image that receives it's compiled methods through the net, from a big image "feeding" it. In software engineering terms, Behavior should definitely not depend on Compiler, that's ridiculous, we could have different compilers, bla bla bla. You can either remove the method Behavior>>compile:, leaving only the interfaces on Compiler, or you could move it to a class extension. Moving it to a class extension will make sure that compile: will only be deployed on images that include the compiler (which is correct), Behavior will not include broken code, and the user will still be able to do self class compile: 'stuff' if he has the right packages loaded. The dependency problem is gone. If Behavior>>codeNavigator is a class extension from the pacakge CodeBrowser, there's no dependency problem. You just need query tools that are class-extension aware, but as I said, some do exist. Daniel Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > > [Why not use class extensions] > >> Because right now we do not have a good way of dealing with class > >> extensions. As soon as > >> we will get a real package notion this will be easy to fix. But may be > >> we should do that now. > >> I did not discuss this point with other. > > > The DVS method-category-name-convention is a hack, but it works. > > Furthermore, PackageInfo itself and SpaghettiTracer provide some query > > tools that are aware of these class extensions. I think that anyone > > refactoring the image now should seriously consider using this kind of > > class extensions. It might not be pretty, but it's better than making > > the code indirect because it can't be put into the correct class. > > I agree with the use of extensions. This is one of the most powerful > open aspect of Smalltalk. We will look at it when we will need them. > > However in the case of systemNavigation I do not see why I would put > them in class > extension on Object. The idea behind the core cleaning is to remove > dependency > and build layer around the core, so systemNavigation is really a layer > on top for UI or global queries as such it is better to add it on the > tools that use it than to add a global dependencies even via class > extension. The fact that I load or not CodeBrowser should not > imply that all the objects depends now from SystemNavigation. I see > class extension as a > really powerful way to add method in a packageable way but we should > pay attention > about the consequences of adding dependency. > > If you check where I was forced to introduced systemNavigation you will > discover that there is > a lot of dirty code there too. For example, SmartStream referring to > UI, Utilities (;)). In Dictionary because we use subclassing to > represent namespaces ;) > So besides them I got a really could reuse for all the tools sharing > stringHolder. > > I hope I was clear. > > Stef

2 1

Re: [Q] Newbie - Multiple Return Values
by Daniel Vainsencher 05 May '03

05 May '03

One problem I see is that since this pattern isn't very common now, I don't have a very clear idea what it should "look like". The most obvious aspect of this is, how to call the methods. Are there lispy conventions for this pattern? (I happened to do something exactly like this for an exercise in The little LISPer, which I'm going through - highly reccommended). Daniel "Richard A. O'Keefe" <ok(a)cs.otago.ac.nz> wrote: > Put it this way, if you have reason to suspect that the object returned > here is likely to acquire new responsibilities and/or new uses, return > a purpose-built object. If you don't have such reason (division is not > likely to return more than a quotient and a remainder) using a block > requires the least coding and is at least better than using an Array.

1 0

Re: KCP feedback (ii)
by Daniel Vainsencher 05 May '03

05 May '03

Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > > About SystemNavigation - it has a nice comment that does answer some of > > the questions I had, but can you say something about how it's supposed > > to fit into everything? for example, why all the similar > > implementations > > of self systemNavigator and not one implementation in Object (wait! > > don't shoot!) in a class extension? it's not very clear in what case > > you'd need state for this bunch of utility methods, so what examples > > did > > you have in mind when you made them instance side? Still would be glad for answers to the rest of these... :-) [Why not use class extensions] > Because right now we do not have a good way of dealing with class > extensions. As soon as > we will get a real package notion this will be easy to fix. But may be > we should do that now. > I did not discuss this point with other. The DVS method-category-name-convention is a hack, but it works. Furthermore, PackageInfo itself and SpaghettiTracer provide some query tools that are aware of these class extensions. I think that anyone refactoring the image now should seriously consider using this kind of class extensions. It might not be pretty, but it's better than making the code indirect because it can't be put into the correct class. Daniel

2 1

Squid modules vs. ClassBoxes (was: Squid language)
by Anthony Hannan 05 May '03

05 May '03

I forget to clarify my description of Squid behaviors/modules with an example. I will use the example presented in the ClassBoxes paper (http://scgwiki.iam.unibe.ch:8080/SCG/559) while comparing the two module schemes. A classBox is a module containing classes and local class extensions to imported classes. It imports classes from other classBoxes. Global vars must refer to local or imported classes, but messages may refer to any interface. Interfaces are global not imported. For example, it may send the #do: message to some argument without importing the Collection interface. I know current Smalltalk does not bind messages to interfaces, but Squid does. I believe it is important to capture the interface because the programmer has to think of the interface to come up with the right message. But as soon as he compiles the method the interfaces he thought of are lost. We can easily capture the interface by having the compiler lookup messages in interfaces visible to the module. There are many benefits to capturing interfaces and few costs. Interfaces add structure explicitly defining module boundaries. It also facilitate type inference. The cost is modeling these interfaces and capturing them, but Squid modules makes this easy. Modeling interfaces is a key divergence between Squid modules and ClassBoxes. A Squid module is a set of methods whose public methods define the module's interface. A module import other modules making their interfaces available to local methods. The module's methods primarily serve to define selectors for the interface, but their implementation define default behavior that is executed if the receiver class does not implement is own version. So the Collection module would define #do: as well as #collect:, #select:, etc. It would implement #collect: and #select: using #do:. A class such as OrderedCollection would override #do: and automatically inherit the default implementation of #collect: and #select:. The OrderedCollection would get this behavior just by implementing #Collection.do: without needing to explicitly subclass from Collection. This allows open multiple inheritance. Notice, #Collection.do: is the full selector name to distingush which interface you are refering to in case some other module also defines #do:. In practice, it is likely that #do: will be unique among all imported modules so the prefix can be elided. A Squid class can only implement methods previously defined in some module, thus overriding it. A class can implement private helper methods but these can not be called from outside the class. Now for the example. The ClassBox paper presents an example of writing a LinkChecker that parse an HTML page into a HTML parse tree, then uses a generic visitor to visit each node in the parse tree. The special LinkChecker visitor responds to #visitLink: by pinging the link destination to see if its up. The HTMLVisitor classBox extends each HTMLParseNode in Squeak with an #acceptVisitor: method and defines a generic HTMLVisitor class. The LinkChecker classBox defines a subclass of HTMLVisitor called LinkChecker that overrides #visitLink: with the code that pings the link. In Squid, the HTMLVisitor module would define #acceptVisitor: and #visitHead:, #visitBody:, #visitLink:, etc. and implement them with default behavior. Each HTMLParseNode class would be directly extended with #HTMLVisitor.acceptVisitor: containing the appropriate implementation. A new LinkChecker class would be created and extended with #HTMLVisitor.visitLink: containing the ping code. The main difference is that Squid add extensions directly to the class while ClassBoxes keeps them in the classBox. But this really is just an implementation difference the two are equivalent. A browser could easily show/edit methods by module or by class in either scheme. In both implementations, the extension methods are bound to the owning module/classBox as well as the base class. In Squid the extension methods reside on the class but are bound to the module via the selector prefix. In ClassBox, the extension methods reside in the classBox but are bound to the class via the class extension syntax. Actually, internally ClassBox also puts the extension methods directly in the class method dictionary with a classBox prefix. In the ClassBox example, they also extend the Socket class with an alternative #ping: method in the LinkChecker classBox. This can be done as well in Squid by defining a #ping: method in a LineChecker module then extending Socket with #LinkChecker.ping:. However, the ClassBox implementation may be implying that this alternative #ping: method will be called even if not called directly from a LinkChecker.visitLink:. This implies dynamic context influencing method lookup. This is different then typical modules whose lookup is determined lexically. Dynamic lookup violates encapsulation and is dangerous. Suppose your code triggers an execution path you did not anticipate that calls #ping: expecting the old behavior. Because it is runs in your context it will use the new #ping: version and break. I'm not sure ClassBox is proposing this but I got this impression. I would handle changes like this to #ping: not using modules but rather with long-lived transaction/version. You would run your app within a certain version. But this is another topic. In Squid class are separate from modules while in ClassBox classes reside in modules. The ClassBox way forces the classes to import the same modules that the rest of the module imports. Squid allow classes to import only what it needs without importing what the rest of the module needs. Also, Squid allows controlled overrides. A subclass may only override methods that call classResponsibility or classMayOverride. This provide an explicit "subclass/polymorphic" interface. For example, the Collection module may define #select:, without override capability making sure it is not overriden improperly. Or it may define a private helper method it does not want subclasses to intercept and abuse. In general though most public methods will be implemented with classMayOverride capability. Finally, not only is Squid modules an alternative to ClassBoxes it is also an alternative to Traits. Each module would be a trait and any class could include any trait just by implementing key classResponsibility methods of the trait. Cheers, Anthony

2 1

Re: [Q] Newbie - Multiple Return Values
by Richard A. O'Keefe 05 May '03

05 May '03

John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: Can't say I've ever seen the block example in code that I've look at so I thought it was neat. Mind I wonder about the expense of doing the block evaluation etc etc from a performance viewpoint. Well, in some Scheme systems that I've benchmarked, the block method is easily the fastest way to return multiple results. When it comes to Squeak, "when in doubt, MEASURE!" 1. Open a browser and make a new class, MVTime. Give it instance variables x, y. 2. Give it an instance method 'x: this y: that x := this. y := that.' 3. Give it an instance method 'xy ^{x. y}' 4. Give it an instance method 'report: ^aBlock aBlock value: x value: y' 5. Give it an instance method 'point: ^x@y' 6. Open a workspace. 7. Type in the setup code mvt := MVTime new a := x := y := this := that := nil. and DoIt. 8. Type in the timing code [100000 timesRepeat: [ mvt x: 1 y: 2. a := mvt xy. x := a at: 1. y := a at: 2 ]] timeToRun. and PrintIt. 9. Type in the timing code [100000 timesRepeat: [ mvt x: 1 y: 2. mvt report: [:this :that | x := this. y := that]] ]] timeToRun and PrintIt 10. Type in the timing code [100000 timesRepeat: [ mvt x: 1 y: 2. a := mvt point. x := a x. y := a y ]] timeToRun For the Array-returning code, I get 1125. For the Block-passing code, I get 867. For the Point-returning code, I get 540. These numbers aren't exactly surprising. Put it this way, if you have reason to suspect that the object returned here is likely to acquire new responsibilities and/or new uses, return a purpose-built object. If you don't have such reason (division is not likely to return more than a quotient and a remainder) using a block requires the least coding and is at least better than using an Array.

1 0

Re: to: squeak ministry of metainformation
by Bill Schwab 05 May '03

05 May '03

Rob, ======================= {HYPERLINK "http://www.economist.com/agenda/displayStory.cfm?story_id=1752211"}http://www.economist.com/agenda/displayStory.cfm?story_id=1752211 The second to last line attributes Apple for pioneering the graphical interface. Perhaps several letters to the editor would be received well by this publication. It's readership is fairly broad. Extolling the research work of Smalltalk and even the broader goals and economic benefits of education through dynamic automation might grab them. cheers, rob ======================= For an economics rag, I'm perhaps a little more interested that they think the flaw in Napster was the central server, not producing an infrastructure for ripping off people who produce intellectual (ok, most of it falls short of that<g>) property. The truly scary thing is how little reading I had to do to get the true story on Smalltalk, GUIs etc. The fact that the _computer_ rags don't demand their authors so inform themselves is sad. Bill Wilhelm K. Schwab, Ph.D. bills(a)anest4.anest.ufl.edu (352) 846-1285

2 1

Re: *ListMorphs
by Daniel Vainsencher 05 May '03

05 May '03

One thing you might consider is that your list should probably be of domain objects, represented by morphs, not a list of morphs. You might find the SM package ColorDevTools (CDT) intersting. I think this is generally an important direction, because more expressive lists would make many interfaces more useful. Daniel tbr(a)mannynkapy.net (Tom Rushworth) wrote: > On Sun, May 04, 2003 at 01:58:20PM +0100, Paul Chapman wrote: > > Are there any plans to build versions of the various list morphs > > which draw their rows directly instead of using a submorph for > > every row? For large lists the current implementation is very slow! > > There are some LargeList enhancements floating around. Check the > list archives and the swiki. My apologies for not having the > references handy. > > > > Cheers, Paul > > > While we're on the subject of ListMorphs, all of the list morphs seem > to expect the submorphs to be string/text morphs, and seem to provide > the submorphs with (effectively) infinite width. I want to display a > list of more complicated morphs where each submorph is a window with > 3 (or more) panes. I want the submorphs to be laid out proportionally > in the horizontal direction, but to be fixed size and scrolled in the > vertical direction. (For anyone who has used Quicken, think of how the > list of transactions in an account is displayed.) > > I just got such a morph working yesterday, but I had to make changes > all over the place :(. Now that I've proved to myself I can do it :), > I can ask the list: is there an obvious, easy way to do this? One that > doesn't involve a dozen new classes and changes to many old classes? > > Also, what should this morph be called? I've called it the > "PluggableMorphListMorh" in the sense of pluggable(MorphList)morph, not > because I like that name (I don't) but because I couldn't think of anything > better. Suggestions anyone? > > If anyone's interested, I'll post it once I get rid all the cruft and > dead end code from the things I tried that didn't work. Right at the > moment I don't think my pride could handle someone else looking at it :). > > Regards, > > -- > Tom Rushworth

2 1

Re: Squid VM
by Anthony Hannan 05 May '03

05 May '03

Hi Michael, as you know I am very interested in distributed objects and have the same vision as you. Michael van der Gulik <mikevdg(a)hetnet.nl> wrote: > - are you thinking in any way about how your language would run on > multiple machines (i.e. by making it possible to have "special" objects > that may act as stubs)? Yes, and since I'm moving message lookup into the image it will be even easier to recognize stubs. > - have you considered how your VM could possibly work on a computer with > multiple processors (processes or CPU's). Not too much, I will have to think about it some more. The goal is model the VM like a real hardware machine and put as much as possible into the image. So maybe the ProcessScheduler in the image would pick an available processor from the VM when resuming a Squid process. > - have you considered having multiple sources for objects - i.e. from > multiple images, object storage databases, remote objects, ... Yes, I have though about loading multiple images (better though of as segments) into the same VM. Cross pointers would still have to be maintained or reified so the segments can be saved to their respective files. It might be just as easy to load each segment in to its own VM and reuse the distributed objects protocol. But the important thing is to support cross pointers between segments (images), which I have always anticipated. Necessary primitives can always be added to the VM to support cross-pointers, multiple processes, etc. But most of the work should be in the image. Support primitives should just provide the necessary access to internal state. > (thought: making assignment ( := ) and reading of variables forms of > message passing that could be overrided would allow these tricks) If your talking about instance variables and global variables, then Squid does exactly that. Inst/Class var assignments and reads are compiled to message sends. However, temp var assignments and reads are compiled to "move" bytecodes. > - And would it be possible to make a language-independant VM, perhaps > with modifications to respective compilers, that could compile and > interpret Squeak, ANSI Smalltalk or Squid. Yes. That is why I'm defining a low-level VM so any compiler can compile to it. Particularly, an adaptive optimizing compiler. Cheers, Anthony

1 0

Re: [ANN] [ENH] FillInTheBlankMorph Look
by Daniel Vainsencher 05 May '03

05 May '03

Could you also replace "Cursor wait showWhile:" patterns with something more abstract? Daniel Avi Bryant <avi(a)beta4.com> wrote: > If nobody's tackled this cleanup by early next week, I volunteer to start > it then. > > Avi

1 0

Re: Aggregated removal script for 3.6
by Daniel Vainsencher 04 May '03

04 May '03

Goran said: > > IMHO we simply need more Harvesters - any whoever is competent (and you > > definitely are) and willing should (again IMHO) be very welcome to help > > out. diegogomezdeck(a)consultar.com wrote: > What about to make a "oficial" call to help? > > I think a lot of us are able to work in this area and I never know > the "door is open". You're right, I think we should, though I at least would not do it *right now*. I think we should have a somewhat clearer idea of how the whole process should work (which will come naturally from giving it a little time, though we might be a little slower than one might desire during this time) and then we'll widen the circle. Daniel

3 2

← Newer
1
...
63
64
65
66
67
68
69
70
71
Older →

Jump to page: