- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

Thanks lukas > I've commented commited :) I guess I saw in on the rss feed :) > a version of RBConfigurableFormatter that can format > #copyFrom: to the following code. This comes pretty close to the > document of Adrian: > > Object>>copyFrom: anotherObject > "Copy to myself all instance variables I have in common with > anotherObject. This is dangerous because it ignores an object's > control over its own inst vars. " > > <primitive: 168> > | mine his | > mine := self class allInstVarNames. > his := anotherObject class allInstVarNames. > 1 to: (mine size min: his size) do: [ :ind | > (mine at: ind) = (his at: ind) > ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. > self class isVariable & anotherObject class isVariable > ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ > :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] > can we get rid of the :ind | ;) > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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 Lukas Renggli

I've commented a version of RBConfigurableFormatter that can format #copyFrom: to the following code. This comes pretty close to the document of Adrian: Object>>copyFrom: anotherObject "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. " <primitive: 168> | mine his | mine := self class allInstVarNames. his := anotherObject class allInstVarNames. 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. self class isVariable & anotherObject class isVariable ifTrue: [ 1 to: (self basicSize min: anotherObject basicSize) do: [ :ind | self basicAt: ind put: (anotherObject basicAt: ind) ] ] -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 28, 2010

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