Squeak-dev August 1998

squeak-dev@lists.squeakfoundation.org

99 participants
188 discussions

Polymorphism and language
by Adam Bridge 02 Aug '00

02 Aug '00

I wonder if we're not asking the wrong question here. Language, it seems to me, is for expression. If we design a language (as opposed to allowing it to evolve) then we should have a goal for that language. What's the goal here? Although polymorphism is certainly an interesting capability shouldn't we be looking at the kinds of tasks we wish to perform? Would we demand an artist work in tempra when water color is what expresses the mood best? Personally I like the idea of small languages that do some things very very well. They are easy to learn because their concepts are clear. If languages can agree on ways to intermingle so I can write my image manipulation in one language and my text in another and my GUI in yet another -- and have them work together intimately and EASILY -- then I think we have a software system which is about expression first and language second. I'd love to easily, trivially, combine Smalltalk, Perl, Fortran, Obj-C and be able to easily explore other languages in this same context: it becomes easy to grow. Adam Bridge

2 1

unsubscribe
by Alek 09 Jun '00

09 Jun '00

2 1

Re: Re: Float bug toolkit: what the hash is this?
by Tim Olson 31 Aug '99

31 Aug '99

>>"[1]" (10 raisedToInteger: 600) = (10.0 raisedToInteger: 800) "alt-p" >>These are equal since both expressions end up answering a float with a >>special value indicating positive infinity. Positive infinities are always >>equal. > >Nonono.... (10 raisedToInteger: 600) is anInteger, while the other (if >finished correctly) is aFloat. Correct. The problem occurs when the #= message is sent to the LargePositiveInteger with the argument a Float (+Infinity). This causes the LargePositiveInteger to be adapted to a Float (resulting in +Infinity, as well). >If aFloat turns out to be infinite, an error >should be posted. This would have to be tested in the Float primitives in the VM whenever an overflow (or NaN, I suppose) is generated. However, I *think* (VM experts correct me, here) that all they can do is fail rather than returning a succesful value, so all of the Float code that invokes primitives would have to be rewritten to test and reflect this overflow/exception failure. The IEEE "default" operation is to silently return the default values (Inf or NaN), rather than generating an exception. What should the standard for Squeak be? -- tim

3 2

Polymorphism without protocol dilution
by m3rabb＠stono.com 01 Sep '98

01 Sep '98

I would appreciate any thought on the following: I though I would add the common method #at:ifAbsentPut: to Dictionary. As the convention varies between dialects, I though it would be useful for the 'ifAbsentPut: parameter' to accept either a value, or a block to be evaluated. My first iteration was: at: key ifAbsentPut: valueObject ^self at: keyObject ifAbsent: [self at: key put: valueObject value] For this to work would require that I add Object>>#value which I remember is a no-no, because it dilutes the BlockContext protocol as Object>>#do: diluted the Collection protocol. We replaced Object>>#do: with #in:, so with what do we replace Object>>#value? Two sets of solutions come immediately to mind: 1) BlockContext>>#selector1 ^self value Object>>#selector1 ^self at: key ifAbsentPut: valueObject ^self at: key ifAbsent: [self at: key put: valueObject selector1] selector1 could be one of the following: a) evaluate b) evaluated c) simplify d) simplified e) asValue f) asValueObject g) asEvaluated h) asEvaluatedObject i) asImmediate j) asImmediateObject 2) BlockContext>>#selector2 ^self Object>>#selector2 ^[self] at: key ifAbsentPut: valueObject ^self at: key ifAbsent: [self at: key put: valueObject selector2 value] selector2 could be one fo the following: a) asBlock b) asBlockContext c) asAction Of my suggestions I prefer set 1 over 2 because set 2 seems more circuitous. Of set 1 I prefer option e. Unfortunately, asValue is already used in other dialects to convert an Object to a ValueHolder/ValueModel. I wish they uses asValueModel (or stuck with ValueModel on: anObject) instead. As far as names go I often wish some of the more fundamental methods were better named so that I could use the name which they currently occupy for something more appropriate (IMHO). Which technique and selector name is recommended? --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

4 5

Mail to disney?
by Christopher Oliver 01 Sep '98

01 Sep '98

In respect for the net tradition of not broadcasting personal correspondence, I try to handle personal responses and disputes via private mail. How does one directly target a person at Disney? I've nothing but good things to say in my messages, but a message to <random>@bobo.rd.wdi.disney.com awaits delivery. As a mail administrator, I find it questionable to make a habbit of speaking with ones ears plugged. Thoughts? Ideas? -- Christopher Oliver Traverse Internet Systems Coordinator 223 Grandview Pkwy, Suite 108 oliver(a)traverse.net Traverse City, Michigan, 49684 Dedicated to perfecting the cluttered desktop metaphor.

3 4

Re: dazed by SortedCollection
by Jon M. DeLaurier 31 Aug '98

31 Aug '98

> <snip> >At 10:28 AM 8/31/98, Patrick Logan wrote: >> The problem with the new versions is that we are forgeting special >> the SortCollection protocol. >> >> #addLast: adds an element without resorting (sneaky) >> >>Why is #addLast allowed to be sneaky but #at:put: is disallowed >>altogether? >> > >SortedCollections are never guaranteed to have any element at a particular >location, just in order. If you insert an element at a location, the ideal >SortCollection will immediately resort itself to stay correct. The element >will more than likely not still be at the location you put it in, making >#at:put: meaningless. By this reasoning _all_ the inherited adding methods >are also meaningless except #add:. To this end I have added: > >SortCollection>>#addWithoutSorting: anObject > ^super add: anObject > >and changed #copyFrom:to: to use #addWithoutSorting: instead of >inappropriately using #addLast:. > >--Maurice > I am dazed and confused! Why would you want to add to a sorted collection without sorting? It seems to me to be a canidate for the more general collection class. So again why have an addLast: method in the SortCollection class?? Jon ------------------------------------------------------------------------- | Jon M. DeLaurier | vox : 250.656.6176 | | 2209 Bradford Av | | | Sidney, B.C. V8L2C8 | | | Canada | email: jdelaurier(a)vanisle.net | ------------------------------------------------------------------------- | It is always darkest just before it gets black. (Dave Broadfoot 1996) | -------------------------------------------------------------------------

2 1

RE: RV: "thisContext selector" (the revenge)
by Alejandro F. Reimondo 31 Aug '98

31 Aug '98

Dan, and all squeakers >However, execute... > 3 perform: #zork: with: 4 >and look at the debugger state. The message is fairly nicely packaged up >...snip... when #zork: is sent to 3; the VM build aMessage (a Message with selector: zork: and arguments: (4 )) as a side effect for handling the #doesNotUnderstand: exeption. Then the debugger can show the message (and the receiver handle the exeption because this message has been created by the VM); but the #perform: does not generates message nor context. Please note that if you evaluate "3 perform: #zork: with: 4" in a workspace you will see the UndefinedObject>>Doit method and the SmallInteger(Object)>>doesNotUnderstand: method; but the SmallInteger(Object)>>perform: method will be absent!. The debugger show you the #perform: because he has the message built by the VM to handle the #doesNotUnderstand:. In my problem the message is always implemented in the receiver using a litte method that connect to the server and download the real method only when needed; then the message does not fail (with #doesNotUnderstand:). Attached to this mail you will find a little example to see the problem I'm trying to solve (in a non-dirty way). Please fileIn this change set and evaluate the expression: SwapperTest new test The test will fail when a #perform: message is sent. WARNING: do NOT save your image and reload the changeset prior to testing again. Ale. ---------- De: Dan Ingalls[SMTP:DanI@wdi.disney.com] Enviado: Martes 25 de Agosto de 1998 09:58 Para: Alejandro F. Reimondo Cc: squeak(a)cs.uiuc.edu Asunto: Re: RV: "thisContext selector" (the revenge) Ale - I'm on the road and can't send a careful answer until later. However, execute... 3 perform: #zork: with: 4 and look at the debugger state. The message is fairly nicely packaged up and will even proceed properly if you define zork: before proceeding. So I would spend a while looking at what the debugger does. It should ultimately answer your need. - Dan >what happens when you send a #perform: message? >It is solved in a primitive method that sends the message inside the VM; > activating a new method context to solve the performed message. >Then, when I look for the sent message in the context, the message found > is #perform:... and the activated method is NOT the #perform implementation >Ouch! >The #perform: implementation does not create a MethodContext because > it is a primitive method! >mmm... >When I search in the contexts (actual and the sender's context) >I can find the #perform: selector, but the arguments are missing >( has been absorbed by primitive) >Provably the problem will be difficult to solve with the contexts >information only... > >Is there any known (easy) way to solve the #perform: problem? > >thanks. >Ale. Attachment converted: Cog:SwapOut.zip (pZIP/pZIP) (0000E167)

2 1

Re: Where is the VW porting stuff?
by Bob Arning 31 Aug '98

31 Aug '98

On Mon, 31 Aug 1998 13:04:56 -0700 Travis Griggs <tgriggs(a)keyww.com> wrote: >A week or so back, there were some posts about various add ons to make filing >in from VW fileouts easier. Did this get gathered together and placed >somewhere, I looked at the Swiki, but didn't see anything... Travis, http://www.charm.net/~arning/Refactoring/ contains several files VWCompiler - a fix to allow the VW specific stuff in the RB files to be filed in SyntaxError - allows the SyntaxError window to open in Morphic so you can see serious problems encounter while filing the stuff in. RefactoringV1 - a very early Squeak version of the RB. I will be uploading a much more useful version fairly soon (this evening, maybe). Cheers, Bob

1 0

Re: Unsubscribing
by Les Tyrrell 31 Aug '98

31 Aug '98

You need to mail someone at UIUC... but I don't know the procedure as that was lost long ago. However, I will chime in with a reccomendation... the following is always the last item I see on messages I get from the Galileo mailing list- I think it is very helpful and not at all intrusive to include this information with every message. I think it would be great if the list server for Squeak were able to append this to the messages it sends out. (begin) # # # # # You are subscribed to the Jet Propulsion Laboratory's galileo listserv. To unsubscribe, e-mail JPLNews(a)jpl.nasa.gov . Leave the subject field blank, and type unsubscribe galileo in the body of the message. (/begin)

5 4

Re: Polymorphism without protocol dilution
by Terry Raymond 31 Aug '98

31 Aug '98

On Mon, 31 Aug 1998 11:12:33 -0700, Travis Griggs wrote: >David N. Smith wrote: > >> I'd like to make a third kind of suggestion for your list. Don't mix blocks >> and other values. Make the protocol different. For example: >> >> at: key ifAbsentPut: anObject >> self at: key ifAbsent: [ self at: key put: anObject ] >> >> at: key ifAbsentPutValue: aBlock >> self at: key ifAbsent: [ self at: key put: aBlock value ] >> >> Another effect of this suggestion is that it still allows putting blocks >> into dictionaries as values, while suggestions 1 and 2 do not. > >Why don't we just add types to Smalltalk! Seriously people, that's what all of >these messages are starting to look like. I can just see some of my methods in >the future: > >at: aKey ifAbsentPutValueOfOneArgBlockThatWontReturnNil: aBlock > >Not that I necessarily have a better solution :). But it worries me when I see >messages whose keyword parts are basically types. A little of this is OK, but I >think it should be used sparingly. Sorry, but in this case, types are not the answer. If types were appropriate I would expect the method to do the same thing but just handle the different types appropriately. However, in this case the block is being evaluated, not just being returned, i.e. the behavior is different. Terry Raymond Crafted Smalltalk (401) 846-6573 http://www.craftedsmalltalk.com

1 0

Jump to page: