I understand the point of not adding more syntax and I agree with it, but I
think this is such big missing feature in Pharo and that it could be
provided by default in the image as an API instead of a syntax sugar.
https://github.com/dvmason/Pharo-Functional has both approaches — syntax
and API — a
Y
> On 26 Jan 2022, at 15:55, gettimothy via Pharo-users
> wrote:
>
> WAIPSessionTrackingStrategy > isAbstract
>^true
> has just ran into my new hobby horse.
>
> I am reading through every class in Seaside to document it and I had an
> 'aha!' moment
>
> on the design of Abstract super c
WAIPSessionTrackingStrategy > isAbstract
^true
has just ran into my new hobby horse.
I am reading through every class in Seaside to document it and I had an 'aha!'
moment
on the design of Abstract super classes like WABrush:
WABrush > isAbstract
^ self == WABrush
On Wed, Jan 26, 2022 at 4:40 AM Sven Van Caekenberghe wrote:
> Hi Kaspar,
>
> I found the initial example actually reasonable readable.
>
> However, I would simplify it as follows:
>
> (json at: #tree)
> select: [ :each |
> ((each at: #type) = #blob)
> and: [ #(md mic) includes: (Path
On Wed, Jan 26, 2022 at 10:58 AM gettimothy via Pharo-users
wrote:
> I realize this is just a preference, but the denseness forces me to think in
> Objects and composition rather than process.
I never thought of it this way, but I fully agree with it. Thanks for
putting this in words.
Maybe wh
Also...learning to think in Smalltalk has taught me to understand Lisp.
As an Emacs guy, that is a good thing (:
I like the parenthesis.
The thinking process is very much like "thinking in Sets" when building a
complex SQL statement.
The result is a lot of power in an dense, elegant expression.
If, as is often the case with me, I find a nested expression as below too
complex, it is very easy to deco
Hi Kaspar,
I found the initial example actually reasonable readable.
However, I would simplify it as follows:
(json at: #tree)
select: [ :each |
((each at: #type) = #blob)
and: [ #(md mic) includes: (Path from: (each at: #path)) extension ] ].
I would personally not try to extend th
Kasper,
I wouldn't say your suggestion looks any more readable than the many
parentheses of the original expression. The whole operation is complex
enough to be hard to understand.
So I agree with both Richard and Sebastian - you should either make the
steps readable by giving the intermediate
But does this help? Now the simple nested query is some serious code.
I, too, like the idea that a query expression like the one shown should have a
nice syntax…
without the need for variables.
I always thought that the nice collection API would be nicer if we could write
them without
parenthe
I agree that the expression is unreadable. What I would initially do is to
extract it into temporary variables.
Like:
tree := json at: 'tree'.
blobs := tree select: [ :each | (each at: 'type') = 'blob' ].
paths := blobs collect: [ :each | Path from: (each at: 'path')]).
...
After you can s
On Wed, Jan 26, 2022, 01:20 Kasper Osterbye
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')]
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
13 matches
Mail list logo
