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

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

by Schwab,Wilhelm K

Lukas, Remember, you asked for it :) This might seem very pedantic, and it is. It is also something that has save my bacon more times than I can count. If the RB can preserve things like this, great, I'll use it more. If not, that's ok too, but I can't have it forced on me. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Monday, March 01, 2010 1:32 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Excellent, thanks for the test case. I will have a look as soon as I get home. Lukas On Monday, March 1, 2010, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Lukas, > > File in the attached and then reformat it. Â I have to admit there has been improvement; at least the comments remain within the cascade of which they were originally a part. Â Still, they end up out of order with respect to the reformatted code, which is devastating to what I am trying to accomplish. Â These are directly analogous to the types of comments that sat (in longer cascades) for several years only to save my back side last year. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas > Renggli [renggli(a)gmail.com] > Sent: Monday, March 01, 2010 7:47 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > >> I'm not complaining; it's simply a fact, and I'm not the only one observing it. Â Links were given here some time back. > > Sorry, but this is only a fact if you provide unit tests (or at least > a couple of examples) that fail in the latest code base. Otherwise > simply nobody cares. > > Lukas > > -- > 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 > -- 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

March 1, 2010

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

by Gary Chambers

Just the issue of "resaved" code then... I suggest a compact format regardelss with "on view" formatting to the user's liking.... Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, March 01, 2010 6:29 PM Subject: Re: [Pharo-project] about code formatting in pharo > Gary, > > That's pretty much what I just proposed based on your suggestion and a > "null" formatter. However it is implemented, the idea is to render the > code using a formatter so the code itself is not altered. That will > hopefully give everyone what they want. Stef, will that work? > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Monday, March 01, 2010 1:26 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > > Perhaps a setting to mark saved code "as is" then? Along with an override > for people who want formatting regardless? > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr>; <dale.henrichs(a)gemstone.com> > Sent: Monday, March 01, 2010 6:23 PM > Subject: Re: [Pharo-project] about code formatting in pharo > > >> Stef, >> >> To that reasoned response I will add that I do not at all care what >> others >> choose to use in their code; I simply don't want a formatter applied to >> my >> code that lives in my image. Whatever works for you and others in the >> core is fine by me. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale >> Henrichs >> Sent: Monday, March 01, 2010 1:07 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Cc: Pharo-project Development >> Subject: Re: [Pharo-project] about code formatting in pharo >> >> Stef, >> >> I really like formatters, but as the discussion has already shown, there >> isn't one format that fits everyone's definition of beauty/readability. >> >> Personally I am willing to use any formatter that saves me from having to >> hand edit code for format, but I think I am in the minority. >> >> Presumably the formatter can be configured to produce different output >> formats ... if the format operation avoided dirtying the method, then >> supporting multiple formats would be less onerous ... I can reformat a >> method in my image using my formatter so that I can read someone else's >> code is pretty useful...Along the same line, having Monticello use the >> canonical formatter to format code when writing out mcz files would >> eliminate format issues for saved mczs (note that for source code >> comparison in Monticello, the canonical formatter should be used on both >> strings), finally it might make sense to format code on read, so that >> noone will ever have to know that their chosen format is not the >> canonical >> one:) ... >> >> Just some thoughts that might minimize the impact of "format wars"... >> >> Dale >> ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: >> >> | Hi guys >> | >> | I would like to build a set of canonical code formatting convention >> | for Pharo. >> | I need your help. Now take time before replying :) I would like to >> | structure the discussion and proceed step by step. So at max I would >> | like to discuss one or two formatting approach per mail. >> | Once we agree I would like to define a wiki page. >> | >> | >> | **Space after : rule >> | ============= >> | for example I would like to always have a space after a : >> | >> | classes := Smalltalk allClasses select:[:aClass| >> | (aClass class includesSelector: #cleanUp) >> | or:[aClass class includesSelector: #cleanUp:] >> | ]. >> | >> | -> >> | >> | >> | classes := Smalltalk allClasses select: [:aClass| >> | (aClass class includesSelector: #cleanUp) >> | or: [aClass class includesSelector: #cleanUp:] >> | ]. >> | >> | >> | **Block arg rule >> | ============= >> | Do we want a space before and after block arg >> | >> | Smalltalk allClasses select: [:aClass :method| >> | >> | -> Smalltalk allClasses select: [ :aClass :method | >> | >> | >> | ** selector or block indented compared to receiver >> | ======================================= >> | >> | Finally do we follow kent block ideas? >> | >> | classes := Smalltalk allClasses select: [:aClass| >> | (aClass class includesSelector: #cleanUp) >> | or: [aClass class includesSelector: #cleanUp:] >> | ]. >> | >> | -> >> | classes := Smalltalk allClasses >> | select: [:aClass| (aClass class includesSelector: #cleanUp) >> | or: [aClass class includesSelector: >> | #cleanUp:]]. >> | >> | Stef >> | _______________________________________________ >> | 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 >> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2010

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

by Lukas Renggli

Excellent, thanks for the test case. I will have a look as soon as I get home. Lukas On Monday, March 1, 2010, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Lukas, > > File in the attached and then reformat it. Â I have to admit there has been improvement; at least the comments remain within the cascade of which they were originally a part. Â Still, they end up out of order with respect to the reformatted code, which is devastating to what I am trying to accomplish. Â These are directly analogous to the types of comments that sat (in longer cascades) for several years only to save my back side last year. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] > Sent: Monday, March 01, 2010 7:47 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > >> I'm not complaining; it's simply a fact, and I'm not the only one observing it. Â Links were given here some time back. > > Sorry, but this is only a fact if you provide unit tests (or at least > a couple of examples) that fail in the latest code base. Otherwise > simply nobody cares. > > Lukas > > -- > 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 > -- Lukas Renggli http://www.lukas-renggli.ch

March 1, 2010

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

by Schwab,Wilhelm K

Gary, That's pretty much what I just proposed based on your suggestion and a "null" formatter. However it is implemented, the idea is to render the code using a formatter so the code itself is not altered. That will hopefully give everyone what they want. Stef, will that work? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Monday, March 01, 2010 1:26 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Perhaps a setting to mark saved code "as is" then? Along with an override for people who want formatting regardless? Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr>; <dale.henrichs(a)gemstone.com> Sent: Monday, March 01, 2010 6:23 PM Subject: Re: [Pharo-project] about code formatting in pharo > Stef, > > To that reasoned response I will add that I do not at all care what others > choose to use in their code; I simply don't want a formatter applied to my > code that lives in my image. Whatever works for you and others in the > core is fine by me. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale > Henrichs > Sent: Monday, March 01, 2010 1:07 PM > To: Pharo-project(a)lists.gforge.inria.fr > Cc: Pharo-project Development > Subject: Re: [Pharo-project] about code formatting in pharo > > Stef, > > I really like formatters, but as the discussion has already shown, there > isn't one format that fits everyone's definition of beauty/readability. > > Personally I am willing to use any formatter that saves me from having to > hand edit code for format, but I think I am in the minority. > > Presumably the formatter can be configured to produce different output > formats ... if the format operation avoided dirtying the method, then > supporting multiple formats would be less onerous ... I can reformat a > method in my image using my formatter so that I can read someone else's > code is pretty useful...Along the same line, having Monticello use the > canonical formatter to format code when writing out mcz files would > eliminate format issues for saved mczs (note that for source code > comparison in Monticello, the canonical formatter should be used on both > strings), finally it might make sense to format code on read, so that > noone will ever have to know that their chosen format is not the canonical > one:) ... > > Just some thoughts that might minimize the impact of "format wars"... > > Dale > ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: > > | Hi guys > | > | I would like to build a set of canonical code formatting convention > | for Pharo. > | I need your help. Now take time before replying :) I would like to > | structure the discussion and proceed step by step. So at max I would > | like to discuss one or two formatting approach per mail. > | Once we agree I would like to define a wiki page. > | > | > | **Space after : rule > | ============= > | for example I would like to always have a space after a : > | > | classes := Smalltalk allClasses select:[:aClass| > | (aClass class includesSelector: #cleanUp) > | or:[aClass class includesSelector: #cleanUp:] > | ]. > | > | -> > | > | > | classes := Smalltalk allClasses select: [:aClass| > | (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: #cleanUp:] > | ]. > | > | > | **Block arg rule > | ============= > | Do we want a space before and after block arg > | > | Smalltalk allClasses select: [:aClass :method| > | > | -> Smalltalk allClasses select: [ :aClass :method | > | > | > | ** selector or block indented compared to receiver > | ======================================= > | > | Finally do we follow kent block ideas? > | > | classes := Smalltalk allClasses select: [:aClass| > | (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: #cleanUp:] > | ]. > | > | -> > | classes := Smalltalk allClasses > | select: [:aClass| (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: > | #cleanUp:]]. > | > | Stef > | _______________________________________________ > | 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 > > _______________________________________________ > 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

March 1, 2010

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

by Schwab,Wilhelm K

Interesting. One chooses a formatter, with a NullFormatter (does nothing to the code) as an option. Works for me. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Monday, March 01, 2010 1:21 PM To: Pharo-project(a)lists.gforge.inria.fr; dale.henrichs(a)gemstone.com Subject: Re: [Pharo-project] about code formatting in pharo The answer is that the code is formatted when viewing, from, potentially, unformatted code. Should please everyone. Of course, nothing to stop code being stored in a compact format then.... Regards, Gary ----- Original Message ----- From: "Dale Henrichs" <dale.henrichs(a)gemstone.com> To: <Pharo-project(a)lists.gforge.inria.fr> Cc: "Pharo-project Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, March 01, 2010 6:06 PM Subject: Re: [Pharo-project] about code formatting in pharo > Stef, > > I really like formatters, but as the discussion has already shown, there > isn't one format that fits everyone's definition of beauty/readability. > > Personally I am willing to use any formatter that saves me from having to > hand edit code for format, but I think I am in the minority. > > Presumably the formatter can be configured to produce different output > formats ... if the format operation avoided dirtying the method, then > supporting multiple formats would be less onerous ... I can reformat a > method in my image using my formatter so that I can read someone else's > code is pretty useful...Along the same line, having Monticello use the > canonical formatter to format code when writing out mcz files would > eliminate format issues for saved mczs (note that for source code > comparison in Monticello, the canonical formatter should be used on both > strings), finally it might make sense to format code on read, so that > noone will ever have to know that their chosen format is not the canonical > one:) ... > > Just some thoughts that might minimize the impact of "format wars"... > > Dale > ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: > > | Hi guys > | > | I would like to build a set of canonical code formatting convention > | for Pharo. > | I need your help. Now take time before replying :) > | I would like to structure the discussion and proceed step by step. So > | at max I would like to discuss one or two formatting approach per > | mail. > | Once we agree I would like to define a wiki page. > | > | > | **Space after : rule > | ============= > | for example I would like to always have a space after a : > | > | classes := Smalltalk allClasses select:[:aClass| > | (aClass class includesSelector: #cleanUp) > | or:[aClass class includesSelector: #cleanUp:] > | ]. > | > | -> > | > | > | classes := Smalltalk allClasses select: [:aClass| > | (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: #cleanUp:] > | ]. > | > | > | **Block arg rule > | ============= > | Do we want a space before and after block arg > | > | Smalltalk allClasses select: [:aClass :method| > | > | -> Smalltalk allClasses select: [ :aClass :method | > | > | > | ** selector or block indented compared to receiver > | ======================================= > | > | Finally do we follow kent block ideas? > | > | classes := Smalltalk allClasses select: [:aClass| > | (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: #cleanUp:] > | ]. > | > | -> > | classes := Smalltalk allClasses > | select: [:aClass| (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: > | #cleanUp:]]. > | > | Stef > | _______________________________________________ > | 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2010

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

by Gary Chambers

Perhaps a setting to mark saved code "as is" then? Along with an override for people who want formatting regardless? Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr>; <dale.henrichs(a)gemstone.com> Sent: Monday, March 01, 2010 6:23 PM Subject: Re: [Pharo-project] about code formatting in pharo > Stef, > > To that reasoned response I will add that I do not at all care what others > choose to use in their code; I simply don't want a formatter applied to my > code that lives in my image. Whatever works for you and others in the > core is fine by me. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale > Henrichs > Sent: Monday, March 01, 2010 1:07 PM > To: Pharo-project(a)lists.gforge.inria.fr > Cc: Pharo-project Development > Subject: Re: [Pharo-project] about code formatting in pharo > > Stef, > > I really like formatters, but as the discussion has already shown, there > isn't one format that fits everyone's definition of beauty/readability. > > Personally I am willing to use any formatter that saves me from having to > hand edit code for format, but I think I am in the minority. > > Presumably the formatter can be configured to produce different output > formats ... if the format operation avoided dirtying the method, then > supporting multiple formats would be less onerous ... I can reformat a > method in my image using my formatter so that I can read someone else's > code is pretty useful...Along the same line, having Monticello use the > canonical formatter to format code when writing out mcz files would > eliminate format issues for saved mczs (note that for source code > comparison in Monticello, the canonical formatter should be used on both > strings), finally it might make sense to format code on read, so that > noone will ever have to know that their chosen format is not the canonical > one:) ... > > Just some thoughts that might minimize the impact of "format wars"... > > Dale > ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: > > | Hi guys > | > | I would like to build a set of canonical code formatting convention > | for Pharo. > | I need your help. Now take time before replying :) I would like to > | structure the discussion and proceed step by step. So at max I would > | like to discuss one or two formatting approach per mail. > | Once we agree I would like to define a wiki page. > | > | > | **Space after : rule > | ============= > | for example I would like to always have a space after a : > | > | classes := Smalltalk allClasses select:[:aClass| > | (aClass class includesSelector: #cleanUp) > | or:[aClass class includesSelector: #cleanUp:] > | ]. > | > | -> > | > | > | classes := Smalltalk allClasses select: [:aClass| > | (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: #cleanUp:] > | ]. > | > | > | **Block arg rule > | ============= > | Do we want a space before and after block arg > | > | Smalltalk allClasses select: [:aClass :method| > | > | -> Smalltalk allClasses select: [ :aClass :method | > | > | > | ** selector or block indented compared to receiver > | ======================================= > | > | Finally do we follow kent block ideas? > | > | classes := Smalltalk allClasses select: [:aClass| > | (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: #cleanUp:] > | ]. > | > | -> > | classes := Smalltalk allClasses > | select: [:aClass| (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: > | #cleanUp:]]. > | > | Stef > | _______________________________________________ > | 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2010

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

by Schwab,Wilhelm K

Stef, To that reasoned response I will add that I do not at all care what others choose to use in their code; I simply don't want a formatter applied to my code that lives in my image. Whatever works for you and others in the core is fine by me. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, March 01, 2010 1:07 PM To: Pharo-project(a)lists.gforge.inria.fr Cc: Pharo-project Development Subject: Re: [Pharo-project] about code formatting in pharo Stef, I really like formatters, but as the discussion has already shown, there isn't one format that fits everyone's definition of beauty/readability. Personally I am willing to use any formatter that saves me from having to hand edit code for format, but I think I am in the minority. Presumably the formatter can be configured to produce different output formats ... if the format operation avoided dirtying the method, then supporting multiple formats would be less onerous ... I can reformat a method in my image using my formatter so that I can read someone else's code is pretty useful...Along the same line, having Monticello use the canonical formatter to format code when writing out mcz files would eliminate format issues for saved mczs (note that for source code comparison in Monticello, the canonical formatter should be used on both strings), finally it might make sense to format code on read, so that noone will ever have to know that their chosen format is not the canonical one:) ... Just some thoughts that might minimize the impact of "format wars"... Dale ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: | Hi guys | | I would like to build a set of canonical code formatting convention | for Pharo. | I need your help. Now take time before replying :) I would like to | structure the discussion and proceed step by step. So at max I would | like to discuss one or two formatting approach per mail. | Once we agree I would like to define a wiki page. | | | **Space after : rule | ============= | for example I would like to always have a space after a : | | classes := Smalltalk allClasses select:[:aClass| | (aClass class includesSelector: #cleanUp) | or:[aClass class includesSelector: #cleanUp:] | ]. | | -> | | | classes := Smalltalk allClasses select: [:aClass| | (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: #cleanUp:] | ]. | | | **Block arg rule | ============= | Do we want a space before and after block arg | | Smalltalk allClasses select: [:aClass :method| | | -> Smalltalk allClasses select: [ :aClass :method | | | | ** selector or block indented compared to receiver | ======================================= | | Finally do we follow kent block ideas? | | classes := Smalltalk allClasses select: [:aClass| | (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: #cleanUp:] | ]. | | -> | classes := Smalltalk allClasses | select: [:aClass| (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: | #cleanUp:]]. | | Stef | _______________________________________________ | 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

March 1, 2010

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

by Gary Chambers

The answer is that the code is formatted when viewing, from, potentially, unformatted code. Should please everyone. Of course, nothing to stop code being stored in a compact format then.... Regards, Gary ----- Original Message ----- From: "Dale Henrichs" <dale.henrichs(a)gemstone.com> To: <Pharo-project(a)lists.gforge.inria.fr> Cc: "Pharo-project Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, March 01, 2010 6:06 PM Subject: Re: [Pharo-project] about code formatting in pharo > Stef, > > I really like formatters, but as the discussion has already shown, there > isn't one format that fits everyone's definition of beauty/readability. > > Personally I am willing to use any formatter that saves me from having to > hand edit code for format, but I think I am in the minority. > > Presumably the formatter can be configured to produce different output > formats ... if the format operation avoided dirtying the method, then > supporting multiple formats would be less onerous ... I can reformat a > method in my image using my formatter so that I can read someone else's > code is pretty useful...Along the same line, having Monticello use the > canonical formatter to format code when writing out mcz files would > eliminate format issues for saved mczs (note that for source code > comparison in Monticello, the canonical formatter should be used on both > strings), finally it might make sense to format code on read, so that > noone will ever have to know that their chosen format is not the canonical > one:) ... > > Just some thoughts that might minimize the impact of "format wars"... > > Dale > ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: > > | Hi guys > | > | I would like to build a set of canonical code formatting convention > | for Pharo. > | I need your help. Now take time before replying :) > | I would like to structure the discussion and proceed step by step. So > | at max I would like to discuss one or two formatting approach per > | mail. > | Once we agree I would like to define a wiki page. > | > | > | **Space after : rule > | ============= > | for example I would like to always have a space after a : > | > | classes := Smalltalk allClasses select:[:aClass| > | (aClass class includesSelector: #cleanUp) > | or:[aClass class includesSelector: #cleanUp:] > | ]. > | > | -> > | > | > | classes := Smalltalk allClasses select: [:aClass| > | (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: #cleanUp:] > | ]. > | > | > | **Block arg rule > | ============= > | Do we want a space before and after block arg > | > | Smalltalk allClasses select: [:aClass :method| > | > | -> Smalltalk allClasses select: [ :aClass :method | > | > | > | ** selector or block indented compared to receiver > | ======================================= > | > | Finally do we follow kent block ideas? > | > | classes := Smalltalk allClasses select: [:aClass| > | (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: #cleanUp:] > | ]. > | > | -> > | classes := Smalltalk allClasses > | select: [:aClass| (aClass class includesSelector: #cleanUp) > | or: [aClass class includesSelector: > | #cleanUp:]]. > | > | Stef > | _______________________________________________ > | 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

March 1, 2010

Re: [Pharo-project] Call for fixing the network problem

by Miguel Enrique CobÃ¡ Martinez

El lun, 01-03-2010 a las 13:21 +0100, Adrian Lienhard escribiÃ³: I haven't had time to test the last change you proposed, but I was thinking that: 1. Test in squeak and if it works, borrow the code from Networking and apply it in Pharo. 2. Revert to previous Networking in Pharo. That depends on how many users are affected by this new code, and the old code. BTW, can someone summary the problems that the old code had and why the new changes were made? So that we can decide? Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 1, 2010

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

by Dale Henrichs

Stef, I really like formatters, but as the discussion has already shown, there isn't one format that fits everyone's definition of beauty/readability. Personally I am willing to use any formatter that saves me from having to hand edit code for format, but I think I am in the minority. Presumably the formatter can be configured to produce different output formats ... if the format operation avoided dirtying the method, then supporting multiple formats would be less onerous ... I can reformat a method in my image using my formatter so that I can read someone else's code is pretty useful...Along the same line, having Monticello use the canonical formatter to format code when writing out mcz files would eliminate format issues for saved mczs (note that for source code comparison in Monticello, the canonical formatter should be used on both strings), finally it might make sense to format code on read, so that noone will ever have to know that their chosen format is not the canonical one:) ... Just some thoughts that might minimize the impact of "format wars"... Dale ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: | Hi guys | | I would like to build a set of canonical code formatting convention | for Pharo. | I need your help. Now take time before replying :) | I would like to structure the discussion and proceed step by step. So | at max I would like to discuss one or two formatting approach per | mail. | Once we agree I would like to define a wiki page. | | | **Space after : rule | ============= | for example I would like to always have a space after a : | | classes := Smalltalk allClasses select:[:aClass| | (aClass class includesSelector: #cleanUp) | or:[aClass class includesSelector: #cleanUp:] | ]. | | -> | | | classes := Smalltalk allClasses select: [:aClass| | (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: #cleanUp:] | ]. | | | **Block arg rule | ============= | Do we want a space before and after block arg | | Smalltalk allClasses select: [:aClass :method| | | -> Smalltalk allClasses select: [ :aClass :method | | | | ** selector or block indented compared to receiver | ======================================= | | Finally do we follow kent block ideas? | | classes := Smalltalk allClasses select: [:aClass| | (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: #cleanUp:] | ]. | | -> | classes := Smalltalk allClasses | select: [:aClass| (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: | #cleanUp:]]. | | Stef | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2010