Squeak-dev September 2005

squeak-dev@lists.squeakfoundation.org

157 participants
266 discussions

Internationalization of SW1 from squeakfoundation
by Samir Saidani 25 Sep '05

25 Sep '05

Hi, I visited the SW1 from http://box2.squeakfoundation.org:7777/, and there is some features I think it should be interesting to include in the Monticello, like the translation ( en | sv ). Is it possible to get the image somewhere ? Or to add this feature to the MC repository ( http://www.squeaksource.com/smallwiki1 ). We can also think how to internationalize such a site ? I don't know if such a feature is planned for SW2... Regards, Samir

5 8

BabyUML overview posted
by Trygve Reenskaug 24 Sep '05

24 Sep '05

Hi all, I have been writing OO programs for 30 years. I have not yet written a significant OO program that made me feel comfortable. (I have not read a sigificant OO program that I could fully understand). The essence of OO is that objects interact to achieve something and the action happens in the inter-object space. Yet my languages (Simula, Smalltalk, Java) force me to focus on a single class/object at the time. I have tried using role models/UML collaborations, but find I cannot keep model and code synchronized. I want increased confidence in my programs. I want my own and other people's programs to be more readable. I want a new discipline of programming that augments my thought processes. BabyUML is a coherent multi-language discipline for coding object interaction and objects/classes. An overview has been posted: http://heim.ifi.uio.no/~trygver/2005/babyuml/newdiscipline.pdf Sorry, folks - it's long (10 pages). The title may be a show stopper: Towards A New Discipline of Programming Enjoy --Trygve P.S. I have, of course, started building BabyUML an extension of Squeak, but it does not appear to be a realistic task for a one-person team. More about that when I see the response to this opener (if any). -- Trygve Reenskaug mailto: trygver(a)ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway

6 10

The Squeak Rectangle as a BabyComponent
by Trygve Reenskaug 24 Sep '05

24 Sep '05

My work with the Islands package and the subsequent discussion has made me realize a very important point: It is relatively easy to pass incoming messages through a gatekeeper such as Islands/farRef. It is much harder to handle the returned values in a proper manner (such as it is done in FarRef). Consider class Rectangle and let's see if it could be a BabyComponent that encapsulates its member objects. There are two "member objects" in an instance of Rectangle: origin and corner. There is only one method that sets these variables directly: Rectangle>>setOrigin: topLeft corner: bottomRight I can interrogate the rectangle by messages such as topLeft, topRight, etc... They all return new Points; a statement such as rect topLeft x: 200 does not change the rectangle - it merely changes the returned point. A very different message is origin. The statement rect origin x: 200 DOES change the rectangle because origin returns the instance variable itself. The Rectangle>>origin method violates the encapsulation by revealing the implementation. This is not acceptable in a BabyComponent because the client shall not be forced to study the implementation to avoid being trapped. I do not often take the time to read my Squeak code right down to the innermost method. I do, of course learn the traps from personal and bitter experience so that I can avoid them in the future. The BabyComponent is a trap-removing device. There is a cost; rect origin is faster than rect upperLeft. My immediate reaction to this renewed study of Rectangle would be to remove the origin message from its public interface and consider adding messages such as left: anInteger. I found 333 senders of origin in my current image. Most of them are probably read-only. But there could, somewhere, be a smart method that used it to modify the rectangle itself. There could even be a subtle bug somewhere... The question is if it would be an advantage to group Squeak objects into components with defined public interfaces and without revealing the member objects. If the answer is yes: Are there examples where it is inappropriate? I've got a new and important issue on my list, thanks to the Islands implementation. --Trygve -- Trygve Reenskaug mailto: trygver(a)ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway

2 1

[Q] Why FillInTheBlank is not enough Smart ?
by Lic. Edgar J. De Cleene 24 Sep '05

24 Sep '05

> > Le comento que para empezar a recordar un poco SmallTalk, trate de > migrar un TP de "paradigmas" hecho en smalltalk V a Squeak (no se si hay > una forma automatica, de todas formas me vino bien hacerlo a pulmon para > ir tocando y acordandome) > El tema es que el programa en un momento necesita que el usuario ingrese > un Float. Como veo que en squeak ya no existe la clase Prompter, busque > otra clase similar y encontre FillInTheBlank. Lo que sucede que esta > clase me devuelve con el metodo "request:" un objeto de tipo ByteString, > y esa clase no admite el metodo asFloat que es el que necesito. > La pregunta concreta es: ¿cual es la forma mas facil de ingresar un float? This was a request from student Basic, he wish something similar to Prompter in Smalltalk V and found FillInTheBlank. I said he should use asNumber , not asFloat. But the real question is : If you could put : | x | x := 3.14159. In a workspace and you have a Float object. Why if you do: | unNumero | unNumero :=FillInTheBlankMorph request: 'Ingrese un número '. unNumero inspect. Answer aByteString object You must do | unNumero | unNumero :=(FillInTheBlankMorph request: 'Ingrese un número ') asNumber. unNumero inspect. Is Squeak not smart as Smalltalk V ? Edgar ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar

2 1

LINQ
by Blake 24 Sep '05

24 Sep '05

Has anyone seen this? http://msdn.microsoft.com/netframework/future/linq/default.aspx It seems so...familiar.

1 0

On the Relevance of RISC[Re: Is Set growth thread-safe?]
by jwalsh＠bigpond.net.au 24 Sep '05

24 Sep '05

---- Blake <blake(a)kingdomrpg.com> wrote: > > I'll give you an answer that is neither authoritative nor comprehensive. > It may, in fact, not address your issue at all, since you started with a > link to RISC, and I don't see the relevance of RISC at all. >

2 1

Re: BabyUML
by Richard Staehli 24 Sep '05

24 Sep '05

Trygve, I applaud this effort to close the gap between design and implementation. I learned the distinction between an objects design "role" and its implementation "class" from your book "Working with Objects". I agree that it is still a huge problem to rely on programmers to realized design constraints expressed in a separate (e.g. UML) language, if at all. I have two main comments. First, your short document ignores related work like the Model Driven Architecture work of the OMG. While you may not have the time to follow all such work, you might find a very knowledgeable audience to critique your BabyUML work through Jan Øyvind Aagedal at SINTEF. Second, I believe the biggest challenge in translating design to implementation is architectural tradeoffs to achieve extra-functional (QoS) properties. Where OO design is concerned with the semantics of communication between objects, much of our implementation is concerned with the look and feel of a GUI or the scalability of algorithms to access persistent data. These architectural tradeoffs are typically made in the context of a particular user environment or assumptions about the deployment resources and loads. As a consequence, they are generally orthogonal to the primary functional decomposition. In AOP terms, these are cross-cutting concerns. If a programmer must specify how to resolve these architectural tradeoffs in BabyUML, then I expect BabyUML will be little better than a visual programming language; it will fail to untangle your spaghetti. Our research in the QuA project (http://home.simula.no:8888/QuA/) suggests that design must be broken up into small components that are pieced together through architectural decisions by either a software architect/engineer, or perhaps by an automated "service planner". I look forward to hearing more about BabyUML. Richard Staehli On Tuesday, September 20, 2005, at 01:10 AM, squeak-dev-request(a)lists.squeakfoundation.org wrote: > BabyUML is a coherent multi-language discipline > for coding object interaction and objects/classes. > > An overview has been posted: > http://heim.ifi.uio.no/~trygver/2005/babyuml/newdiscipline.pdf > > Sorry, folks - it's long (10 pages). > > The title may be a show stopper: > Towards A New Discipline of Programming > > Enjoy > --Trygve > > P.S. > I have, of course, started building BabyUML an extension of Squeak, > but it does not appear to be a realistic task for a one-person team. > More about that when I see the response to this opener (if any). > > -- > > Trygve Reenskaug mailto: trygver(a)ifi.uio.no > Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver > N-0378 Oslo Tel: (+47) 22 49 57 27 > Norway

2 1

Re: Is a SkyHook Safe[Re: Is Set growth thread-safe?]
by jwalsh＠bigpond.net.au 24 Sep '05

24 Sep '05

I strongly object to that remark Rado. I do not troll, I target a very specific problem, which very few on this list will take seriously, and I stick to it, until I get an answer. Personal insults will not drive me from the issue. I have always strongly defended my point of few, which I believe to be relevant to the very survival and or success of Smalltalk80. If you do not have an answer to my question, then why make a comment at all. Snide remarks from the gallary, is in fact a very old, and nasty tactic. You have the choice Rado to ingnore the topic and move on. I do not deny that my comments are NOT targeted at Programming, but at Design. Smalltalk is an IDE, not a just a Language, there is Development too. In fact IDE does not even refer to a specific Language at all. Development covers a wide spectrum from the IDEA to Implementation. Last but not least it is supposed to be Integrated. Integration is the very thing which is threatened by the extreme OPEN factions. It is impossible to programm your way out of a mess. Design it out. I consider Programming per se to be the skill equivalent of laying bricks. Bricklayers don't necessarily Design nor do they Architect houses. The same applies for Computer Systems. The number of Computer Assisted Design systems available, is few. But Languages? there are hundreds and growing by the day. Just take a look at Wikipedia "hello world" and you will see what I mean. I'll leave it at that ---- radoslav hodnicak <rh(a)4096.sk> wrote: > > I say go back to trolling the vwnc list, or preferably some > smalltalk-unrelated list. > > thanks, rado > > On Fri, 23 Sep 2005, jwalsh(a)bigpond.net.au wrote: > > > Sorry for the rude subject line. > > > > Most may not know what a SkyHook is, and for those who don't, it is a joke. > > There is a limit to the number of "work-arounds", even for Smalltalk. > > Smalltalk is simply not designed for it. [yet]. > > > > Ref: > > http://en.wikipedia.org/wiki/RISC > RISC: Definition and Much More From Answers.com : > > > > I think the above definition is not bad and will a serve as a solid Principle upon which to build anArgument: > > > > 1. Smalltalk as an IDE should not need to call upon extranious program support, unless it respects the rules of Smalltalk. That is why it is called IDE. > > 2. The Smalltalk problems are ALL introduced ones. > > 3. Smalltalk demands the "Software be Designed First and Programmed Later". > > > > If the intended Application Software Design, prior to coding Smalltalk (or any other language for that matter), were given the same RISC teatment in software, as in RISC hardware, then we'd have less RISK. > > Furthermore, I sugget, many of the tactics provided so far , would be unecessary. > > > > What say you? >

2 1

Re: BabyUML
by jwalsh＠bigpond.net.au 23 Sep '05

23 Sep '05

Richard, I applaud your opening remarks. I only wish I could be so succinct. My anger at being accussed of Trolling, is quickly gone. I will ruminate on the rest of your email, over a good cup of tea. Thank you for a glimpse of light at the end of a long tunnel. "Proccede Desire with Design" Justin ---- Richard Staehli <rastaehli(a)mac.com> wrote: > Trygve, I applaud this effort to close the gap between design and > implementation. I learned the distinction between an objects design > "role" and its implementation "class" from your book "Working with > Objects". I agree that it is still a huge problem to rely on > programmers to realized design constraints expressed in a separate > (e.g. UML) language, if at all. > > I have two main comments. First, your short document ignores related > work like the Model Driven Architecture work of the OMG. While you may > not have the time to follow all such work, you might find a very > knowledgeable audience to critique your BabyUML work through Jan Øyvind > Aagedal at SINTEF. > > Second, I believe the biggest challenge in translating design to > implementation is architectural tradeoffs to achieve extra-functional > (QoS) properties. Where OO design is concerned with the semantics of > communication between objects, much of our implementation is concerned > with the look and feel of a GUI or the scalability of algorithms to > access persistent data. These architectural tradeoffs are typically > made in the context of a particular user environment or assumptions > about the deployment resources and loads. As a consequence, they are > generally orthogonal to the primary functional decomposition. In AOP > terms, these are cross-cutting concerns. If a programmer must specify > how to resolve these architectural tradeoffs in BabyUML, then I expect > BabyUML will be little better than a visual programming language; it > will fail to untangle your spaghetti. Our research in the QuA project > (http://home.simula.no:8888/QuA/) suggests that design must be broken > up into small components that are pieced together through architectural > decisions by either a software architect/engineer, or perhaps by an > automated "service planner". > > I look forward to hearing more about BabyUML. > > Richard Staehli > > On Tuesday, September 20, 2005, at 01:10 AM, > squeak-dev-request(a)lists.squeakfoundation.org wrote: > > > BabyUML is a coherent multi-language discipline > > for coding object interaction and objects/classes. > > > > An overview has been posted: > > http://heim.ifi.uio.no/~trygver/2005/babyuml/newdiscipline.pdf > > > > Sorry, folks - it's long (10 pages). > > > > The title may be a show stopper: > > Towards A New Discipline of Programming > > > > Enjoy > > --Trygve > > > > P.S. > > I have, of course, started building BabyUML an extension of Squeak, > > but it does not appear to be a realistic task for a one-person team. > > More about that when I see the response to this opener (if any). > > > > -- > > > > Trygve Reenskaug mailto: trygver(a)ifi.uio.no > > Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver > > N-0378 Oslo Tel: (+47) 22 49 57 27 > > Norway > >

1 0

FW: [CLASSICBOOKS] Classic Computer Science texts - request from Dave Patterson for suggestions
by klaus.witzel＠cobss.com 23 Sep '05

23 Sep '05

Hi all, please take a moment of your time and enter suggestions for classic books related to Smalltalk. I've already suggested The Langugage And Its Implementation. /Klaus -----Original Message----- From: Classic Books List [mailto:classics@ACM.ORG] On Behalf Of classicbooks Sent: Friday, September 23, 2005 18:29 To: classics(a)ACM.ORG Subject: [CLASSICBOOKS] Classic Computer Science texts - request from Dave Patterson for suggestions Dear ACM Member, ACM is launching a new initiative to revive classic, out-of-print computer science books, with the intent to make the full text available online to members via the PDC/DL. I'm asking you to identify the books you believe are "classics." The suggestions I've received so far can be viewed at http://www.acm.org/csclassics/. You may also nominate classic computer manuals (for example, IBM 360 Principles of Operation, and DEC PDP-11 Handbook). The book must be out of print to qualify. (A book is still considered "in print" if its fourth edition is selling despite the first edition being no longer available). Please submit your comments and candidates for CS classics by Friday, October 7, including why you think your nomination(s) qualify as classic(s), by filling out the form at www.acm.org/csclassicspoll . After this date we will conduct a vote, resulting in the Top 20 classic books. You will receive another email with instructions directing you to the Web site with the online poll. Thanks in advance for your help. We believe this will be a great service to our members! Dave Patterson, ACM President

2 1

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

Jump to page: