Squeak-dev September 2001

squeak-dev@lists.squeakfoundation.org

168 participants
408 discussions

Fwd: Re: Storing and Retrieving Point
by John M McIntosh 28 Sep '01

28 Sep '01

>Date: Thu, 27 Sep 2001 20:25:09 -0700 >To: raymondasselin(a)sympatico.ca >From: John M McIntosh <johnmci(a)smalltalkconsulting.com> >Subject: Re: Storing and Retrieving Point >Cc: >Bcc: >X-Attachments: > >> >>John >>What you say is new to me >> >>-There is lots of examples in Smalltalk which suggest something like >>Morph new, or Foo new, so for me this was not linked to the use of >>declaring the type of a variable. >>-I know that when you try to define new for a Class you defined, Squeak >>answer a caution 'new is used in the existing class system......' I >>usually ignore it and go forward. >> >>Your remark is intriguing to me...did this means that it's not a good >>way to go to define a 'new' as a 'builder' Class method in Squeak ? >>I'm a little bit 'confus' because before your note I was pretty sure >>that pt_ Point new. was the way to go !!! >> >>Raymond > >Ok, well this can be a complicated subject. When you create an >instance you face the issue of instance creation and how the >designer of the class wants you to do it. If he has a "complete >instance creation method", usually found in the class instance >creation category, then you can use that. > >Doing a new on the class then poking at the instance might also >work, but then again it might not correct. > >For a simple example > >thing _ OrderedCollection with: #foo > >versus >thing _ OrderedCollection new. >thing add: #foo. > >Both achieve the same results, but as you see they are different. > >A more complex example might be >thing _ ComplicatedDataBaseConnector useHost: 'database.apple.com' > >If you invoke new against ComplicatedDataBaseConnector it might not >do everything you need and you need to invoke other methods against >the instance that require more knowledge to arrive at the same >state. Also if someone wants to change how the instance creation >method useHost: worked, then you could be impacted if you had new >and various other methods to achieve the same state. Some classes >for example forbid the use of new because of this issue. > > >new and overriding new. > >You get the warning because you are messing with an issue. Typically >you add a new method to your class to do ^super new initialize > >This is to allow the inherited class the ability to run new, then >you run your initialization to set anything up that is required. Go >take a look at OrderedCollection new: versus new. > >new does >^self new: 10 > >new: anInteger does >^ super new setCollection: (Array new: anInteger) > > >In this case as you see new actually invokes new: which then invokes >super new and pokes at itself to set instance variables. One could >have had an instance side initalization method aka ^super new >initialize: anInteger. to do this instead, but 20 years back it was >written the way it was. > >basicNew >I seem to recall various folks have written lots of papers on this >so I'm not going to attempt much discussion here, but some people >feel that at some point in a root class you need to invoke ^super >basicNew initialize. to reduce redundant initialization of instance >variables. Also there are other reasons for invoking basicNew. > > >But back to your question about Point new the correct way, if not >for the fact we get an instance of Point by using the @ (technically >it's a binary operator @ against a instance of Number which invokes >primitive 18) you could either do > >pt _ Point x: 100 y: 200. > >or >pt _ Point new. >pt setX: 100 setY : 200 > >Both are correct, but one is more elegant. > >Hint try 10 @ 'hello' >is always interesting to invoke on people, something about what is a >language definition, versus usage of the definition. > >-- > >-- >=========================================================================== >John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 >Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >=========================================================================== -- -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

RE: Computerchannel.de: Squeak 3.0 tested
by G.J.Tielemans＠dinkel.utwente.nl 28 Sep '01

28 Sep '01

No, you have to separate all those good intentions and efforts of you and all the other builders AND the way all this work shows to the world: This article suggest that... > -----Original Message----- > From: Bijan Parsia [mailto:bparsia@email.unc.edu] > Sent: donderdag 27 september 2001 15:38 > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: Computerchannel.de: Squeak 3.0 tested > > > On Wed, 26 Sep 2001, Gary Fisher wrote: > > > Thank you, Bert. Your translation is much better than what > Babelfish > > managed. <g> > > Yay Bert! (The "Yay" is almost always superfluous :)) > > > Some of the article's conclusions are at least marginally > valid, but others > > imply the author entirely missed the point. > > [snip] > > Or, as other folks pointed out, was grossly ignorant...and not just of > Squeak. > > I.e., it seemed to suggest that the only directed-toward-kids > programming > language is an early-80's Logo. > > Plus, I got the impression that they didn't look at any of the *kid's* > stuff in Squeak. Oh well, yadda yadda yadda. > > Cheers, > Bijan Parsia. > > > >

4 4

Re: putting a project on BSS
by Bob Arning 28 Sep '01

28 Sep '01

On Fri, 28 Sep 2001 02:04:13 +0100 John Hinsley <jhinsley(a)telinco.co.uk> wrote: >I've finally got the Rolodex_Project to a point where it will dial out. >This is in advance of writing it up, so I thought I might try and put it >on BSS so people can play with it. (It's quite important that people do >try and play with it, especially on platforms other than Linux, so I can >see if the serial port stuff works for them ;-) ). > >But, (and BSS seems very slow tonight, anyway) how exactly? John, - create a morphic project - if there is (and it certainly looks like it in this case) Smalltalk code necessary for the project to work, be sure that the current change set contains that code - choose 'Publish to Different Server' from the menu that pops up when you click and hold the Publish button in the project navigator - fill in useful information in the dialog called 'Please describe this project' (click the More button) - select 'Bobs SuperSwiki' from the blue file picker and click Save - when asked if you want changes to be included, answer yes That should do it. As to the very slow, it could be - it's only a residential DSL line - it's too popular ;-) - my ISP has problems sometimes - another virus trying to eat the internet - some debugging code I added the other day caused t to run out of memory (I restarted it) Cheers, Bob

1 0

Re: Storing and Retrieving Point
by Richard A. O'Keefe 28 Sep '01

28 Sep '01

raymondasselin(a)sympatico.ca wrote: > >pt _ Point new. > >pt _ 25@125. -There is lots of examples in Smalltalk which suggest something like Morph new, or Foo new, so for me this was not linked to the use of declaring the type of a variable. -I know that when you try to define new for a Class you defined, Squeak answer a caution 'new is used in the existing class system......' I usually ignore it and go forward. Your remark is intriguing to me...did this means that it's not a good way to go to define a 'new' as a 'builder' Class method in Squeak ? I'm a little bit 'confus' because before your note I was pretty sure that pt_ Point new. was the way to go !!! John's point was that in "1" pt _ Point new. "2" pt _ 25@125. the first step is superfluous. In optimising compiler terms, the value it constructs is "dead", it can never be used. The code that creates a new Point has no side effects, so it doesn't accomplish anything useful to create a new point and then throw it away. The second step does not modify the Point created in line "1", it constructs a whole new Point & just rebinds the variable pt. #new is indeed the usual selector for creating new objects. It's not the only one. In this case, "3" pt _ Point x: 25 y: 125. would have had the same effect as step "2". There is actually a problem with using Point new. We normally think of a Point as an object having some kind of number for an x coordinate and some kind of number for a y coordinate (and possibly other stuff it is belongs to a subclass of Point), but "1" pt _ Point new returns a new point such that pt x is nil and pt y is nil. Another way to come up with a suitable point would be "4" pt _ Point new x: 25; y: 125. or "1'" pt _ Point new. "2'" pt x: 25; y: 125.

1 0

Re: Storing and Retrieving Point
by Bob Arning 28 Sep '01

28 Sep '01

Ken, The literal array syntax "#()" only handles literals - symbols, strings, numbers, characters. Thus it interprets pt as #pt. Either dict at: 'first' put: {'text'. pt}. or dict at: 'first' put: (Array with: 'text' with: pt). will do what you want. Cheers, Bob On Thu, 27 Sep 2001 14:08:53 -0600 "Ken G. Brown" <kbrown(a)tnc.com> wrote: >I'm having trouble storing and retrieving Points. What am I doing wrong? > >pt _ Point new. >pt _ 25@125. >dict _ Dictionary new. >dict at: 'first' put: #('text' pt). >readPt _ ((dict at: 'first') at: 2). "readPt is now a Symbol"

2 1

RE: Localization in code
by Richard A. O'Keefe 28 Sep '01

28 Sep '01

"Andreas Raab" <Andreas.Raab(a)gmx.de> wrote: I've deliberately chosen my example of what I *don't* want to do because I've done localization on Windows and, man, it's a pain in the neck to have all these steps whenever you want to write some string that you eventually want to be localized: * define some name you can eventually remember (more often than not you can't) * perhaps even give it some numeric ID manually (haven't done any of that stuff recently so I don't know if MSVC and companions got any smarter in this respect) There are a couple of ways that UNIX does/has done this: msg = catgets(Open_Message_Catalogue_Descriptor, Message_Set_Number, Message_Number, Default_String_To_Use_If_Not_Defined_In_Catalogue); That's the kind of interface where you have to invent a number. msg = gettext(Default_Message_String); is the kind of interface where you don't: the default string is itself all the identifier you need. There is also msg = dgettext(Domain_Name, Default_Message_String); where Default_Name is a string playing the same role as Message_Set_Number. If I just had to consider UNIX, I would set up some kind of Locale class, where Locale default => the "C" locale Locale native => same as what setlocale("") gives you Locale for: '<lang>[_<region>][.<char encoding>]' aLocale getText: 'Default Message String' aLocale getText: 'Default Message String' inDomain: 'Domain Name' aLocale domain => the name of the current domain aLocale domain: 'Domain Name' and then I might whack getText: into Smalltalk with the definition getText: aString ^Locale native getText: aString Locale objects would also handle character classification, time and date conversion, number and money formatting, following the GRASP "Expert" pattern. Then the first step of internationalisation would just be to replace 'Quit' with Smalltalk getText: 'Quit' and so on. None of the C compilers I've used on MacOS, up to MacOS 8.6 (I've refused an upgrade to 9.x), has supported C locales nontrivially. What does MacOS X do?

1 0

RE: Localization in code
by Norton, Chris 28 Sep '01

28 Sep '01

Andreas, I spent a bit more time thinking about this issue. In the interests of getting started, I dashed off a class that can perhaps serve as the beginnings of the localization of strings in Squeak. I haven't spent a heck of a lot of time on this, but perhaps you can use this as a starting point tonight -- I've got to get home and get some dinner in me. Fortunately, you're living 3 hours earlier in the day! Cheers, ---==> Chris PS> My thinking is that we might simply use a LocalizedString instead of a String when we need to display something to the user. A LocalizedString is basically just a wrapper on a dictionary of translated strings (at: language symbol put: translated string). Of course, there is no reason why we can't also use LocalizedString to also hold specialized strings, like Yoshiki's special strings.

1 0

Re: Storing and Retrieving Point
by Richard A. O'Keefe 28 Sep '01

28 Sep '01

"Ken G. Brown" <kbrown(a)tnc.com> wrote: I'm having trouble storing and retrieving Points. ... pt _ Point new. ... dict at: 'first' put: #('text' pt). You are not having any trouble with points. Think of "#" as being like Lisp's "quote". This is exactly equivalent to (setf (gethash "first" dict) (QUOTE #("text" pt))) In Smalltalk terms: #(...) is an array literal, in which everything inside the () is implicitly quoted as if there were a # in front of every element. What you want is dict at: 'first' put: {'text'. pt}

1 0

Re: Localization in code
by raymondasselin＠sympatico.ca 28 Sep '01

28 Sep '01

"Andreas Raab" <Andreas.Raab(a)gmx.de> wrote: > Folks, > > Goeran wrote: > > I know nothing about the scripting system, but it looks neat. I did > > notice though that this translation sofar does not cover all > > texts that show up, far from it. > > I have been thinking about it various times and there's one big problem > associated with localization - it's basically that you don't want to have it > getting into your way when you work and still be very flexible about what > you can do. I really hate a working style where you write something like: > > self inform: MSG_VALUE_IS, value printString. > > and then go into some external resource where you define > > MSG_VALUE_IS: 'The value is '. > > So here's a different proposal (which reflects my latest thoughts on the > problem and I'd like to get some feedback on it). I'm deliberately not > looking at localizing strings that are created "free-style" such as the > "Welcome to" window but exclusively those that are embedded in code and > therefore - at least in theory - harder to translate. My proposal is simple: > > What we need first of all is some sort of "named printf" - e.g., a print > operation that inserts formatted arguments but not by their respective > position (like the C printf where printf("The value of %s is %d", "cargo", > cargo) results in "The value of cargo is 5"). The reason why I really want > to have named arguments is because different languages may translate > arguments in different order and it may well be that an appropriate > localization of the above would be "5 is the value of cargo". Thus I'm > looking for something that can be used along the lines of > > 'The value of <name> is <value>' > printWith: {#name. 'cargo'. #value. cargo}. > > [Note: The above is ugly as hell and one of the reasons why I haven't done > anything yet - I need help and creative ideas how this can be expressed in > an easier way. Please chime in!] > > Then, using such a scheme (or a similar one) we could localize the system > based on some sort of localization browser. What I'm imagining here is that > we have a browser showing us all places where a) #printWith: and (at least > for a transition phase) b) literal strings are used. To localize a method > you'd just "rewrite" that method in the browser but rather than recompiling > it, the system would remember that "String literal A in method X with date > stamp Y was changed to B". The browser saves that information in some > localization file. When you want to switch from one language to another, the > system would load the appropriate localization file and replace all those > literals that it knows about (in other words, where the stamp matches the > actual method stamp so that we don't accidentally localize methods that have > changed in the meantime). > > Once an initial localization is complete we can use the localization browser > to show us the methods that have changed in the mean time (based on their > stamps) and see if we need to do something about it (more often than not we > won't have to and based on the prior method versions we should even be able > to determine this). Which means that after an initial phase localization is > really an incremental thing with (hopefully) little manual effort. > > What do you think?! > > Cheers, > - Andreas Andreas, this seems to me very interesting but I wonder what will happen with diacritics characters and the Smalltalk interpreter ? May be my apprehension is wrong but by now except in 'comments' these characters won't fit. Just try to select in a browser a string like this 'hégémonie'. If you double clik the 'm' you'll select 'monie' !!

2 1

putting a project on BSS
by John Hinsley 28 Sep '01

28 Sep '01

I've finally got the Rolodex_Project to a point where it will dial out. This is in advance of writing it up, so I thought I might try and put it on BSS so people can play with it. (It's quite important that people do try and play with it, especially on platforms other than Linux, so I can see if the serial port stuff works for them ;-) ). But, (and BSS seems very slow tonight, anyway) how exactly? Cheers John -- Can't cope anymore? Desperate for help? Join the 12 step program for those who yearn to give up Microsoft: http://home.earthlink.net/~penguinrox/index.html

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
41
Older →

Jump to page: