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 |
On 20 April 2011 23:18, Ted F.A. van Gaalen <[hidden email]> 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. |
In reply to this post by TedVanGaalen
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 |
On 21 April 2011 07:58, Tobias Pape <[hidden email]> 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. |
> 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 |
On 21 April 2011 17:37, Lukas Renggli <[hidden email]> 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. |
> 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 |
On 21 April 2011 18:06, Lukas Renggli <[hidden email]> wrote:
>> 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." > Sure it is. Unless you turn it into message send with trick which you described above. But then it become even worse from performance point of view, because of use of block closure for doing simple increment. so, people will be punished from using i++ instead of i := i + 1 which i finding amusing :) -- Best regards, Igor Stasenko AKA sig. |
'dnanietiM izeürG' asSchweizerString reversed, '!'
O dear, I've really stirred up++ things :o) Coincidently I, was in Helvetiae today, 110 km from where I currently live (Ravensburg) near Appenzell, had an unprepared ascend++ from Wasserau to the higher Seealpsee. So beautiful. Lungs bursting, heart pumping. but now i feel good! Get away from those screens from time to time! New for me: Looked up Helvetia in a bird's eye view. thanks. Will read more there too. How far does one go? I do like the SQL extension though. Not that I am important or so, far from it, but you can read more about me on linkedIn. I am trying to switch from many other languages/systems to Smalltalk, with the goal of finding a job where I can use it sooner better than later. I did often mainframe (PL/1, Cobol, DB2) projects with the same kind of fun as someone working on old locomotives on a historic railway. I have made my CV as a Seaside Smalltalk app, could put it in a Monticello package and would like to ask you to take a look at it and tell me how I am doing? If so: but where to place the .mcz? it contains a html tree as well. The idea is to put it on a Seaside server for everyone to see.(especially those who could employ me, as i am currently without work) There will be more than just the CV, e.g. UML diagrams and a technical description. Thanks. Won't write so much off topic next time, sorry :o) On Thu, Apr 21, 2011 at 7:19 PM, Igor Stasenko <[hidden email]> wrote: > On 21 April 2011 18:06, Lukas Renggli <[hidden email]> wrote: >>> 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." >> > > Sure it is. Unless you turn it into message send with trick which you > described above. > But then it become even worse from performance point of view, because > of use of block closure for doing simple increment. > > so, people will be punished from using > > i++ > > instead of > > i := i + 1 > > which i finding amusing :) > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Free forum by Nabble | Edit this page |