April 2011 - Pharo-users - lists.pharo.org

Re: [Pharo-users] ++ -- again

by Lukas Renggli

> So, what is your point? To prove your (quoted) sentence wrong: "And it works only for numbers (no pointers in smalltalk) and so, completely falls out of object model." Lukas -- Lukas Renggli www.lukas-renggli.ch

April 21, 2011

Re: [Pharo-users] ++ -- again

by Igor Stasenko

On 21 April 2011 17:37, Lukas Renggli <renggli(a)gmail.com> wrote: >> A ++ operator is evil, because you cannot override or redefine it >> (like any other message). > > In C++ you can. > yep.. been there >> And it works only for numbers (no pointers >> in smalltalk) >> and so, completely falls out of object model. > > It can be done and has been done in Helvetia without falling out of > the object model. > > I don't remember the details, but I was essentially rewriting > > Â Â i++ > > to something along > > Â Â i increment: [ :v | i := v ] > > where you the semantics of #increment: are implemented in the objects > as you wish. For numbers this would be something like: > > Â Â Number>>#increment: aBlock > Â Â Â Â ^ aBlock value: self + 1 > > For other objects other 'meaningful' implementations can be added, for example: > > Â Â SequenceableCollection>>#increment: aBlock > Â Â Â Â ^ aBlock value: self allButFirst , (Array with: self first) > > Â Â Stream>>#increment: aBlock > Â Â Â Â ^ aStream skip: 1 > > Â Â etc. > So, what is your point? Yes, we can extend a syntax. And with Helvetia this is piece of cake. The question - do we need it so much that want to sacrifice a syntax simplicity, consistency and clarity for that? (outside of serving as an example of extending syntax ;) Well, yeah, we can introduce weird stuff at any moment. Things like macros or quasi-quotes will eventually turn once self-explanatory smalltalk code into DSL, where only author can understand what it does... I am fine with having DSLs around with any possible extensions that people may want them to be. But making it to be default syntax? Hell no! -- Best regards, Igor Stasenko AKA sig.

April 21, 2011

Re: [Pharo-users] ++ -- again

by Lukas Renggli

> A ++ operator is evil, because you cannot override or redefine it > (like any other message). In C++ you can. > And it works only for numbers (no pointers > in smalltalk) > and so, completely falls out of object model. It can be done and has been done in Helvetia without falling out of the object model. I don't remember the details, but I was essentially rewriting i++ to something along i increment: [ :v | i := v ] where you the semantics of #increment: are implemented in the objects as you wish. For numbers this would be something like: Number>>#increment: aBlock ^ aBlock value: self + 1 For other objects other 'meaningful' implementations can be added, for example: SequenceableCollection>>#increment: aBlock ^ aBlock value: self allButFirst , (Array with: self first) Stream>>#increment: aBlock ^ aStream skip: 1 etc. Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch

April 21, 2011

Re: [Pharo-users] [COTDC] 52 - PCXReadWriter

by StÃ©phane Ducasse

open a bug entry and put your fix :) Stef On Apr 21, 2011, at 1:05 AM, Guillermo Polito wrote: > I am an Image ReadWriter supposed to be in charge of PCX file encoding and decoding. > > Actually, as my instances does not implement understandsImageFormat, they use the default ^false implementation and I cannot be used. > I don't have uses in the image also :). > > But in case I am fixed, the code to open a morph with a pcx image is: > > PCXReadWriter formFromFileNamed: 'anImage.pcx'. > > > ;) > Guille > > On Wed, Apr 20, 2011 at 3:17 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Today: PCXReadWriter > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

April 21, 2011

Re: [Pharo-users] ++ -- again

by Igor Stasenko

On 21 April 2011 07:58, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > Am 2011-04-20 um 22:18 schrieb Ted F.A. van Gaalen: > >> Thanks Tobias and Igor for your thoughts about this increment/decrement theme. >> @Tobias: what kind of side effect(s) are you talking about? I don't >> understand, sorry. > > No problem, I wrote a bit complicated. > What I mean is that > Â Â Â Â i++ > instructs the object âiâ to change its state, ie, increment > itself. > However, the Object in âiâ is meant to be an > integer. So, how to interpret that? say, âiâ is 5. > Essentially, > Â Â Â Â i++ > says > Â Â Â Â âfive, change your state to be sixâ > But that would imply, because all integers are the respecive same > over the image, that all fives are suddenly sixes. > > The point is, > in C, variables denote memory cells, and it is a common > operation to say âmemory cell, increment your content by oneâ, > whereas in Smalltalk, a variable denotes an object and > such an increment is rather senseless on integer objects. > > In other words, each integer in a Smalltalk image is > a kind of Singleton. > ( Â Â Â as > Â Â Â Â 1 = 1 " => true" > Â Â Â Â 1 == 1 " => true" > ) > Hence, > | a b | > a := 1. > b := 1. > a = b " => true (a and b have the same content)". > a == b "=> true (ie, they are the indentical object)". > > "but" > > a ++. "hypothetical" > a = b "=> ??, probably false". > a == b " => ??, can't think of that". > yes, because variables in smalltalk are references to objects. and variables in C are memory pointers. A ++ operator is evil, because you cannot override or redefine it (like any other message). And it works only for numbers (no pointers in smalltalk) and so, completely falls out of object model. > > So Long, > Â Â Â Â -Tobias > -- Best regards, Igor Stasenko AKA sig.

April 21, 2011

Re: [Pharo-users] ++ -- again

by Tobias Pape

Am 2011-04-20 um 22:18 schrieb Ted F.A. van Gaalen: > Thanks Tobias and Igor for your thoughts about this increment/decrement theme. > @Tobias: what kind of side effect(s) are you talking about? I don't > understand, sorry. No problem, I wrote a bit complicated. What I mean is that i++ instructs the object âiâ to change its state, ie, increment itself. However, the Object in âiâ is meant to be an integer. So, how to interpret that? say, âiâ is 5. Essentially, i++ says âfive, change your state to be sixâ But that would imply, because all integers are the respecive same over the image, that all fives are suddenly sixes. The point is, in C, variables denote memory cells, and it is a common operation to say âmemory cell, increment your content by oneâ, whereas in Smalltalk, a variable denotes an object and such an increment is rather senseless on integer objects. In other words, each integer in a Smalltalk image is a kind of Singleton. ( as 1 = 1 " => true" 1 == 1 " => true" ) Hence, | a b | a := 1. b := 1. a = b " => true (a and b have the same content)". a == b "=> true (ie, they are the indentical object)". "but" a ++. "hypothetical" a = b "=> ??, probably false". a == b " => ??, can't think of that". So Long, -Tobias

April 21, 2011

Re: [Pharo-users] ++ -- again

by Igor Stasenko

On 20 April 2011 23:18, Ted F.A. van Gaalen <tedvga(a)gmail.com> wrote: > Thanks Tobias and Igor for your thoughts about this increment/decrement theme. > @Tobias: what kind of side effect(s) are you talking about? I don't > understand, sorry. > > @Igor, Yes, I completely agree with you that Smalltalk should not > transform to a C++ like dialect. Â At first, I simply would like wanted > ++ -- (monadic) and for that matter also += -= Â *= and /= Â (dyadic) as > messages for the Integer classes, possibly as primitive methods. > > But then again, If this would be implemented, I can imagine people > using ugly and hard to read statement trains like > anotherInt += anInt ++ * 1234 , > I don't find these constructs very nice either.. So, after realizing > this.. perhaps you're right: just let it be. Â (probably would have > needed here () as wel) Yes. As to me it is simply not worth to dedicate a special operator for increment or decrement. It makes no sense, considering how many other operators you could imagine, and considering how often you using value increment in smalltalk. If you do things right, you don't need to write it by yourself , because it is done once in #to:do: and/or #do: loops. So, it is really very small number of use cases where you may need to use increment or decrement. Unlike from C, where you will use ++ or -- on almost every loop , in smalltalk for loops you using collections and closures, incread of manually writing them again and again. -- Best regards, Igor Stasenko AKA sig.

April 21, 2011

Re: [Pharo-users] [COTDC] 52 - PCXReadWriter

by Guillermo Polito

I am an Image ReadWriter supposed to be in charge of PCX file encoding and decoding. Actually, as my instances does not implement understandsImageFormat, they use the default ^false implementation and I cannot be used. I don't have uses in the image also :). But in case I am fixed, the code to open a morph with a pcx image is: PCXReadWriter formFromFileNamed: 'anImage.pcx'. ;) Guille On Wed, Apr 20, 2011 at 3:17 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: PCXReadWriter > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

April 20, 2011

Re: [Pharo-users] Pharo-users Digest, Vol 16, Issue 31

by Anthony Romo

On Tue, Apr 19, 2011 at 4:05 AM, <pharo-users-request(a)lists.gforge.inria.fr>wrote: > Send Pharo-users mailing list submissions to > pharo-users(a)lists.gforge.inria.fr > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > or, via email, send a message with subject or body 'help' to > pharo-users-request(a)lists.gforge.inria.fr > > You can reach the person managing the list at > pharo-users-owner(a)lists.gforge.inria.fr > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pharo-users digest..." > > > Today's Topics: > > 1. Re: [ANN] new mailinglist for tracker mails (Igor Stasenko) > 2. Re: [ANN] new mailinglist for tracker mails (Marcus Denker) > 3. Request for mentor(s) within Pharos community (Anthony Romo) > 4. Re: Request for mentor(s) within Pharos community > (St?phane Ducasse) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 Apr 2011 13:08:22 +0200 > From: Igor Stasenko <siguctua(a)gmail.com> > Subject: Re: [Pharo-users] [ANN] new mailinglist for tracker mails > To: A friendly place where any question about pharo is welcome > <pharo-users(a)lists.gforge.inria.fr> > Message-ID: <BANLkTik+AJv4QxMX3oPMP9saJicHiBf5=A(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 18 April 2011 08:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > The mails from the google tracker now go to this list: > > > > ? ? ? ? > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker > > > > in turn, this means the traffic on the pharo-project list should be a bit > more managable. > > > > Err > > Which language do you prefer to display your messages? Fran?ais > > I prefer english, but there is no option how i could change that. > :( > > > ? ? ? ?Marcus > > > > > > -- > > Marcus Denker ?-- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > > ------------------------------ > > Message: 2 > Date: Mon, 18 Apr 2011 13:16:02 +0200 > From: Marcus Denker <marcus.denker(a)inria.fr> > Subject: Re: [Pharo-users] [ANN] new mailinglist for tracker mails > To: A friendly place where any question about pharo is welcome > <pharo-users(a)lists.gforge.inria.fr> > Message-ID: <C6ED0C16-1999-48C6-A2D4-8AE12B34E0B0(a)inria.fr> > Content-Type: text/plain; charset=iso-8859-1 > > > On Apr 18, 2011, at 1:08 PM, Igor Stasenko wrote: > > > On 18 April 2011 08:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> The mails from the google tracker now go to this list: > >> > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker > >> > >> in turn, this means the traffic on the pharo-project list should be a > bit more managable. > >> > > > > Err > > > > Which language do you prefer to display your messages? Fran?ais > > > > I prefer english, but there is no option how i could change that. > > :( > > > This is good for learning. :-) > > But I changed it. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > > > ------------------------------ > > Message: 3 > Date: Mon, 18 Apr 2011 17:31:27 -0600 > From: Anthony Romo <romo.alromo.anthony73(a)gmail.com> > Subject: [Pharo-users] Request for mentor(s) within Pharos community > To: pharo-users(a)lists.gforge.inria.fr > Message-ID: <BANLkTinUh6XqrGz=DYw4uguNV031D1SG4Q(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Today I joined the pharo-users mailing list. I am a masters degree > candidate in software design. I would appreciate an email from member(s) > of > the community that would be willing to communicate with me and give me a > quick start as to how best to participate in the community. >

April 20, 2011

++ -- again

by Ted F.A. van Gaalen

Thanks Tobias and Igor for your thoughts about this increment/decrement theme. @Tobias: what kind of side effect(s) are you talking about? I don't understand, sorry. @Igor, Yes, I completely agree with you that Smalltalk should not transform to a C++ like dialect. At first, I simply would like wanted ++ -- (monadic) and for that matter also += -= *= and /= (dyadic) as messages for the Integer classes, possibly as primitive methods. But then again, If this would be implemented, I can imagine people using ugly and hard to read statement trains like anotherInt += anInt ++ * 1234 , I don't find these constructs very nice either.. So, after realizing this.. perhaps you're right: just let it be. (probably would have needed here () as wel) Greetings from Ravensburg area TedvG

April 20, 2011