Hi Kasper, perhaps not what you are asking, but I find that this kind of nesting happens to me when parsing serialized data (web page sources or JSON as in your example). For me, the root cause of the problem is that these data structures are not represented by real classes in my code. I often start with what you are showing in a Playground, but then refactor it into specific parsers for the web sites I am scraping. The parsing selectors go into classes that mirror the parts of the data I am interested in. I find this to be more declarative and maintainable, and more natural in the Pharo environment with its browsers and code extractors.
I hope this is of any use :) cheers Siemen On Fri, Jan 28, 2022 at 11:55 PM Vitor Medina Cruz <vitormc...@gmail.com> wrote: > I think that's OK when you can choose when to use parentheses. If you > think it would improve readability it is ok to use it, the problem is to be > forced to use it even when you think it decreases readability, what I > believe to be the case in discussion. > > On Thu, Jan 27, 2022 at 3:24 PM Russ Whaley <whaley.r...@gmail.com> wrote: > >> What I like about parentheses (and I hate parentheses) is that it allows >> me to view/describe the intent of the code. When parens are not used, it is >> up to me (perhaps years later) to determine whether the original developer >> (sometimes me) understood (or not) the actual 'order of processing'. >> Parens - or another vehicle - should help me understand the intent (as >> would detailed comments) - so I can devise tests (oh yeah, are those >> available, too?) for the intent - even if it is just me in the debugger. >> >> So, I'm for whatever helps me understand the intent of the code - even if >> there is some slick way to nest everything. I generally prefer breaking >> nested processes down into multiple steps. Benchmarking rarely shows >> significant performance differences, for me. >> >> (and I've used parentheses 7 times in this one email!) :-) >> >> Russ >> >> On Wed, Jan 26, 2022 at 4:20 AM Kasper Osterbye < >> kasper.oster...@gmail.com> wrote: >> >>> Cheers all >>> >>> I have noticed that I often ends up with quite a number of nested >>> expressions, for example: >>> >>> (((json at: 'tree') >>> select: [ :e | (e at: 'type') = ‘blob' ]) >>> collect: [:e | Path from: (e at: 'path')]) >>> select: [ :p | p segments last >>> in: [ :name | (name endsWith: '.md') | >>> (name endsWith: '.mic') ] ] >>> >>> What kind of proposals (if any) have been for a different syntax which >>> could give a more streamlined syntax? >>> >>> My own thinking has been around an alternative to the cascade semicolon. >>> What symbol to use does not matter for me, but something like >>> json at: ‘tree' º >>> select: [ :e | ((e at: 'type') = 'blob’)]º >>> collect: [:e | Path from: (e at: 'path’)]º >>> select: [ :p | p segments last >>> in: [ :name | (name endsWith: '.md') | (name endsWith: >>> '.mic') ] ] >>> >>> Basically, a send the right hand expression to the result of the left >>> hand expression. >>> >>> Has anyone ever tried this, or is it just one of the many small >>> annoyances best left alone? >>> >>> Best, >>> >>> Kasper >> >> >> >> -- >> Russ Whaley >> whaley.r...@gmail.com >> >
