- Pharo-dev - lists.pharo.org

[Pharo-project] Completion in Pharo?

by Alexandre Bergel

Dear List, Before we have the Mac menu, Cmd-Q was completing a symbol being written. Is there a new mapping for this? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Michael Rueger

On Wed, Dec 24, 2008 at 12:30 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > I am not saying that the smalltalk conventions are bad, what I am saying > is that the flexibility to break the conventions is useful in OTHER > CONTEXTS, and in many ways makes it possible to have other use cases in > the first place. Then break them in the other contexts, but not for the whole system. If you allow abuse of the language, people will do it. Michael

Dec. 24, 2008

Re: [Pharo-project] A design question

by Alexandre Bergel

It depends whether it makes sense or not to have a different threshold for objects. Maybe an expert in gui may help to answer this... Alexandre On 23 Dec 2008, at 19:19, StÃ©phane Ducasse wrote: > Hi > > I would like to get your point of view on the following: > In Object there is the method > > updateThresholdForGraphicInViewerTab > "When a Viewer is open on the receiver, its tab needs some graphic to > show to the user. Computing this graphic can take quite some time so > we want to make the update frequency depending on how long it takes to > compute the thumbnail. The threshold returned by this method defines > that the viewer will update at most every 'threshold * > timeItTakesToDraw' milliseconds. Thus, if the time for computing the > receiver's thumbnail is 200 msecs and the the threshold is 10, the > viewer will update at most every two seconds." > ^20 "seems to be a pretty good general choice" > > which is only defined on Object. > and only called by > > ThumbnailMorph>>stepTime > "Adjust my step time to the time it takes drawing my referent" > drawTime ifNil:[^ 250]. > ^(objectToView updateThresholdForGraphicInViewerTab * drawTime) max: > 250. > > and I was thinking ok this a nice hook and may be it should be a > morphic extension on > Object. On the other hand it seems that this is a feature that is only > use by one class > that is not even core. So may be we could put the magic number inside > the step time. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Keith Hodges

Michael Rueger wrote: > On Wed, Dec 24, 2008 at 10:58 AM, <bryce(a)kampjes.demon.co.uk> wrote: > > >> This is a language design point. Is the convenience of knowing that >> an argument is never modified worth more than the convenience of being >> able to modify the argument? >> > > What really is the convenience of modifying an argument? Having not to > > Breaking the kind of conventions makes you think harder about what > code does and that distracts you from what you really trying to do. Or > should be doing ;-) > But you are not getting it. The point is about context. In the context of smalltalk the conventions make sense. BUT the whole point being there are other contexts even within the same environment. Sake/Packages uses a smalllalk class as a database of package definitions, this is another context. My Mantis package uses a class to document fixes this is another context. Class returns #compilerClass, this means it is possible to put a different compiler in there. Therefore it is expected that there be different contexts within the one environment. I am not saying that the smalltalk conventions are bad, what I am saying is that the flexibility to break the conventions is useful in OTHER CONTEXTS, and in many ways makes it possible to have other use cases in the first place. Keith

Dec. 24, 2008

Re: [Pharo-project] Parsing problem

by StÃ©phane Ducasse

>>> >>> to: stop by: step >>> ... >>> >>> [ : stop : step | ... ] >> >> It looks a weak argument to me :) >> I would hate to teach that. >> I neither thought you could even do that. > > Just for the record, what Lukas described (the part where the args > to block should look like keyword-less keyword message sending) is > indeed the original intention of Dan. (As you probably already knew.) Thanks I was not aware of that and funnily enough I'm a rather visual person and it never occurred to me that this was the case, even today I see what you mean but I have problem to match them in fast eye mode may be because of the absence of characters before.

Dec. 24, 2008

Re: [Pharo-project] Parsing problem

by Yoshiki Ohshima

At Thu, 18 Dec 2008 19:55:31 +0100, StÃ©phane Ducasse wrote: > > On Dec 18, 2008, at 6:34 PM, Lukas Renggli wrote: > > >> I've discussed with Stephane and may be we can fix all the methods > >> that have : > >> _ instead of := > >> or some methods have [ : myArg ... ] instead of [ :myArg .... ] > > > > I agree that the use of := should be enforced. I would also like to be > > able to use _ in names. > > > > However: The parser should allow spaces after the $: in block > > arguments. This is essentially the same syntax as for keyword method > > declarations without a keyword and there you also allow arbitrary > > spaces after the colon (normally you even put them there). So I > > understand when people write block arguments the same way as they do > > for keyword method declarations: > > > > to: stop by: step > > ... > > > > [ : stop : step | ... ] > > It looks a weak argument to me :) > I would hate to teach that. > I neither thought you could even do that. Just for the record, what Lukas described (the part where the args to block should look like keyword-less keyword message sending) is indeed the original intention of Dan. (As you probably already knew.) -- Yoshiki

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

+1 even if I understand since from time to time I need to add a new local to modify an arg. Now I have the impression that when I have to do that it may be better to have an instance variable instead. Stef On Dec 24, 2008, at 11:11 AM, Michael Rueger wrote: > On Wed, Dec 24, 2008 at 10:58 AM, <bryce(a)kampjes.demon.co.uk> wrote: > >> This is a language design point. Is the convenience of knowing that >> an argument is never modified worth more than the convenience of >> being >> able to modify the argument? > > What really is the convenience of modifying an argument? Having not to > think up another name? I never understood this argument especially if > you need to use the original value of the argument in several places. > > IMHO it is all about how much mental load reading code imposes (the > readability Stephane mentioned). > > If we allow modification of arguments, then I can't just look at code > and "know" that the argument has the value it was passed. > > Same with shadowed variables, a truly horrible idea. I look at code > and see an inst var, but fail to notice it is also an argument or > method var and I'm off being confused about what the code does. > > Same for upper/lowercase conventions, let alone uppercase method > names. > > Breaking the kind of conventions makes you think harder about what > code does and that distracts you from what you really trying to do. Or > should be doing ;-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Hilaire Fernandes

Yes, that's the point. 2008/12/24 Michael Rueger <m.rueger(a)acm.org>: > Breaking the kind of conventions makes you think harder about what > code does and that distracts you from what you really trying to do. Or > should be doing ;-)

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Michael Rueger

On Wed, Dec 24, 2008 at 10:58 AM, <bryce(a)kampjes.demon.co.uk> wrote: > This is a language design point. Is the convenience of knowing that > an argument is never modified worth more than the convenience of being > able to modify the argument? What really is the convenience of modifying an argument? Having not to think up another name? I never understood this argument especially if you need to use the original value of the argument in several places. IMHO it is all about how much mental load reading code imposes (the readability Stephane mentioned). If we allow modification of arguments, then I can't just look at code and "know" that the argument has the value it was passed. Same with shadowed variables, a truly horrible idea. I look at code and see an inst var, but fail to notice it is also an argument or method var and I'm off being confused about what the code does. Same for upper/lowercase conventions, let alone uppercase method names. Breaking the kind of conventions makes you think harder about what code does and that distracts you from what you really trying to do. Or should be doing ;-) Michael

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

Yes this is the question and the effort to be different. I always thought this constraint was because of an optimization in early days such as been able to depop without taking care. Stef On Dec 24, 2008, at 10:58 AM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > StÃ©phane Ducasse writes: >> In that case we could change that. But then we would produce >> incompatible code >> also. > > Compatibility is less of an issue for this change as Pharo will accept > more code rather than less. It will not stop us importing any code > that currently runs on Squeak unlike enforcing lower case letters for > instance variable names. > > It may be necessary to copy modified arguments with some optimised > closure implementations but that shouldn't add much complexity. The > current BlockContext implementation copies all it's arguments into the > surrounding MethodContext. > > I think Eliot's closure implementation treats modified variables > different to read only variables. However, to do this it needs > to do the analysis to find which variables are read only in a block > and which can be written to so even in this case writable arguments > will add little implementation complexity and nothing in the VM/JIT. > > This is a language design point. Is the convenience of knowing that > an argument is never modified worth more than the convenience of being > able to modify the argument? > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008