February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

Hi James > Lukas do you have some code samples. >> Something that I particularly hate is the following >> >> self bla ifTrue: [ >> ... >> >> ] ifFalse: [ >> ... >> ] > > I'd like to understand what it is about the above you hate. See levente In addition I have to apy extreme attention to see that the two branches are sent to the same conditional > >> That is see in the code. >> >> I want >> self bla >> ifTrue: [ ... >> ] >> ifFalse: [ >> ... ] > > Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line? > > James > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

you know go (the language) includes in the language the formatting so there is no discussion. Now I really like to see smalltalk code and not C code because..... It slows me down a lot when I read and I read a lot of code. :) Stef On Feb 28, 2010, at 8:51 PM, Adrian Lienhard wrote: > Hi Bill, > > Don't worry. Nobody wants to force you to use his conventions :) > > The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule. > > Cheers, > Adrian > > On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote: > >> Adrian, >> >> Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always. >> >> I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!! >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard >> Sent: Sunday, February 28, 2010 8:11 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] about code formatting in pharo >> >> I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". >> >> According to these rules I would format the following example: >> >> --------------- >> 1 to: (mine size min: his size) do: >> [ :ind | >> (mine at: ind) = (his at: ind) >> ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. >> --------------- >> >> as: >> >> --------------- >> 1 >> to: (mine size min: his size) >> do: [ :index | >> (mine at: index) = (his at: index) ifTrue: [ >> self >> instVarAt: index >> put: (anotherObject instVarAt: index) ] ]. >> --------------- >> >> Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. >> >> Cheers, >> Adrian >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

+ 10 >> I'd like to understand what it is about the above you hate. > > It's like C code, not like a message send. Do you write code like this? > > aCollection do: [ :each | > ... > ] separatedBy: [ > ... > ] > >> >>> That is see in the code. >>> >>> I want >>> self bla >>> ifTrue: [ ... >>> ] >>> ifFalse: [ >>> ... ] >> >> Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line? >> > > IMHO, if the code in the first block is short enought, then it's only a single line, otherwise not, for example: > > self bla > ifTrue: [ self bar ] > ifFalse: [ > ... ] > > self bla > ifTrue: [ > ... ] > ifFalse: [ > ... ] > > This book has great guidelines: > http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf > > > Levente > > > >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

thanks adrian On Feb 28, 2010, at 2:11 PM, Adrian Lienhard wrote: > I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". > > According to these rules I would format the following example: > > --------------- > 1 to: (mine size min: his size) do: > [ :ind | > (mine at: ind) = (his at: ind) > ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. > --------------- > > as: > > --------------- > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) ifTrue: [ > self > instVarAt: index > put: (anotherObject instVarAt: index) ] ]. > --------------- > > Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. :) why not like that? > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) > ifTrue: [ self > instVarAt: index > put: (anotherObject instVarAt: index) ] ].

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

> > runTest: aSelector > > | actualResult expectedResult | > [ self > logTest: aSelector; > clearLog; > perform: aSelector ] > on: MyTestError do: > [ :ex | self log: 'Unhandled Exception'. > ex return: nil ]. > > as you can see, its a bit hard to quickly determine, where ends one > block and starts another one. > That's why i'm always putting ' ] ' at the next line, and align its > indentation to be the same as in opening brace: > > [ self > logTest: aSelector; > clearLog; > perform: aSelector > ] > on: MyTestError do: > [ :ex | self log: 'Unhandled Exception'. > ex return: nil > ]. > > do you agree that this one is much more readable Not for me :) May be I read too much Smalltalk code I prefer the rectangle approach of the first one ;)

Feb. 28, 2010

[Pharo-project] [ANN 1.1] pre-built 1.1#11239

by Marcus Denker

http://gforge.inria.fr/frs/download.php/26559/PharoCore-1.1-11239-UNSTABLE.… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 28, 2010

Re: [Pharo-project] Scamper revival

by Schwab,Wilhelm K

There is the further concern about the browser. It wastes screen space (which is at a premium) and adds weight and distracting functionality. There is something to be said for the a fat client app that does what it needs to do and nothing else. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eagle Offshore Sent: Sunday, February 28, 2010 2:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Scamper revival I wouldn't be so sure. http://html5demos.com/ http://jqtouch.com/ On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: > there is no way in hell that HTML+CSS+JavaScript is going to keep up _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by Schwab,Wilhelm K

Adrian, I appreciate the reassurance, and agree that conventions are a good idea. I further agree with Lukas that a formatter is a good way to get there, but want to make the case for doing that in a way that does not force the hands of end-user (which I appear to have done). Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 2:52 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Hi Bill, Don't worry. Nobody wants to force you to use his conventions :) The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule. Cheers, Adrian On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote: > Adrian, > > Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always. > > I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!! > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Adrian Lienhard > Sent: Sunday, February 28, 2010 8:11 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > > I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". > > According to these rules I would format the following example: > > --------------- > 1 to: (mine size min: his size) do: > [ :ind | > (mine at: ind) = (his at: ind) > ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. > --------------- > > as: > > --------------- > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) ifTrue: [ > self > instVarAt: index > put: (anotherObject instVarAt: index) ] ]. > --------------- > > Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. > > Cheers, > Adrian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] Introducing Myself / FFI comments

by csrabak＠bol.com.br

I would like to add to this discussion. The issue on "breaking code compatibility" /per se/ it is not the central issue, the real trouble is to have to expend too much time to learn how to "re-compatibilize" the cote, or use [the] new construct that is not deprecated. I'm not an active Python developer, but I used to work in a place where it was used extensively and the 'elbow' feedback I got from colleagues was that that Python did a good job on this aspect. my 0.01999.... -- Cesar Rabak Em 28/02/2010 05:24, Hilaire Fernandes < hilaire(a)ofset.org > escreveu: Andreas Raab a Ã©crit : > The *one* tradeoff I wasn't willing to make for the sake of my users was > to break their code; was to make their code non-loadable for absolutely > no benefit for these users. Cleaning up two methods and fifty lines of > code isn't worth breaking six years of work from lots of people. It > wasn't then, it isn't today. However, breaking code compatibility is very common in opensource world, probably to ease evolution. I remember to read somewhere it happens several time in Python, an alive and kicking community... _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by Adrian Lienhard

Hi Bill, Don't worry. Nobody wants to force you to use his conventions :) The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule. Cheers, Adrian On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote: > Adrian, > > Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always. > > I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!! > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard > Sent: Sunday, February 28, 2010 8:11 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > > I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". > > According to these rules I would format the following example: > > --------------- > 1 to: (mine size min: his size) do: > [ :ind | > (mine at: ind) = (his at: ind) > ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. > --------------- > > as: > > --------------- > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) ifTrue: [ > self > instVarAt: index > put: (anotherObject instVarAt: index) ] ]. > --------------- > > Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. > > Cheers, > Adrian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010