@groovy.apache.org
Subject: Re: .with() variant that returns the original object
+1
I like that you provide both .with(true, Closure) and .tap(Closure)
Best regards,
Søren Berg Glasius
GR8Conf Europe organizing team
GR8Conf ApS
Mobile: +45 40 44 91 88, Web: www.gr8conf.eu<http://www.gr8conf.eu/>,
, Gl. Rye, 8680 Ry, Denmark
--- GR8Conf - Dedicated to the Groovy Ecosystem
From: Guillaume Laforge
Reply: users@groovy.apache.org
Date: 15. november 2016 at 09.24.36
To: users@groovy.apache.org
, Paul King
Subject: Re: .with() variant that returns the original object
Sounds good to me
Sounds good to me!
On Tue, Nov 15, 2016 at 9:17 AM, Paul King wrote:
> Ok, disussion seems to have finished on this topic. I was planning to
> merge Christoph's PR with minor tweaks as needed. I was going to use
> 'tap' as the name.
>
> At this stage, unless I hear violent objections, I was also
Ok, disussion seems to have finished on this topic. I was planning to
merge Christoph's PR with minor tweaks as needed. I was going to use
'tap' as the name.
At this stage, unless I hear violent objections, I was also planning
to provide the additional variant that was discussed:
with(boolean ret
On Thu, Nov 10, 2016 at 6:45 AM, Jordan Martinez
wrote:
> What about `object.itselfWith(Closure)`? Then its understood as returning
> the object itself but with the changes that follow.
Both variants use 'itself' but only one returns 'itself', so I would
regard that prefix as not distinguishing e
On Thu, Nov 10, 2016 at 6:47 AM, James Kleeh wrote:
> What about something like object.build { } ?
If you are solely using 'with' to build an object and 'with' by itself
isn't good enough Groovy also has the @Builder annotation. Probably
best we don't confuse normal 'with' with the @Builder trans
From: Jochen Theodorou [mailto:blackd...@gmx.org]
> Sent: Wednesday, November 09, 2016 1:45 PM
> To: users@groovy.apache.org
> Subject: Re: .with() variant that returns the original object
>
> On 09.11.2016 14:56, Winnebeck, Jason wrote:
>> My concern about "withThis&
nt: Wednesday, November 09, 2016 1:45 PM
To: users@groovy.apache.org
Subject: Re: .with() variant that returns the original object
On 09.11.2016 14:56, Winnebeck, Jason wrote:
> My concern about "withThis" is that it implies that "this" is the parameter
> of the closure
What about something like object.build { } ?
> On Nov 9, 2016, at 3:45 PM, Jordan Martinez
> wrote:
>
> What about `object.itselfWith(Closure)`? Then its understood as returning the
> object itself but with the changes that follow.
>
> Blessings,
> Jordan
>
> On Wed, Nov 9, 2016 at 12:32 PM,
What about `object.itselfWith(Closure)`? Then its understood as returning
the object itself but with the changes that follow.
Blessings,
Jordan
On Wed, Nov 9, 2016 at 12:32 PM, Paul King wrote:
> On Thu, Nov 10, 2016 at 12:02 AM, Cédric Champeau
> wrote:
> > I agree with what Jason said. I'm s
On Thu, Nov 10, 2016 at 12:02 AM, Cédric Champeau
wrote:
> I agree with what Jason said. I'm still up for `tap`. We could use
> `with(true) { ... }`, but I also dislike "with(returnThis: true) {... }"
> because it's not type safe.
If we progress GROOVY-7956, we'd have type safety but I agree with
On Thu, Nov 10, 2016 at 4:44 AM, Jochen Theodorou wrote:
> ... And I just noticed Paul made the very same mistake in the original post
> already.
Ah yes, it should be return it or return "implicitThis" not return this.
Cheers, Paul.
, 5000 Odense C, Denmark
Personal Address: Hedevej 1, Gl. Rye, 8680 Ry, Denmark
--- GR8Conf - Dedicated to the Groovy Ecosystem
From: OC
Reply: users@groovy.apache.org
Date: 9. november 2016 at 20.33.17
To: users@groovy.apache.org
, Jochen Theodorou
Subject: Re: .with() variant that returns
Jochen,
On 9. 11. 2016, at 19:44, Jochen Theodorou wrote:
...
> Also it should be noted that we already have an alias for "with", which is
> "identity". I would not want to have yet another one.
> Frankly... I think we should change what it returns.
whilst I agree too many aliases is a bad thin
On 09.11.2016 14:56, Winnebeck, Jason wrote:
My concern about "withThis" is that it implies that "this" is the parameter of
the closure and not the return. We have for example withReader, withWriter, withOutputStream, etc.
Those all imply that the parameter is the reader, the writer, the output
...@asert.com.au
Subject: Re: .with() variant that returns the original object
I agree with what Jason said. I'm still up for `tap`. We could use `with(true)
{ ... }`, but I also dislike "with(returnThis: true) {... }" because it's not
type safe.
2016-11-09 14:56 GMT+01
s or
> .with(returnThis:true), or the equally cryptic .with(true).
>
> Jason Winnebeck
>
> -Original Message-
> From: Philip Mitchell [mailto:pjmitch...@blueyonder.co.uk]
> Sent: Tuesday, November 08, 2016 7:53 PM
> To: users@groovy.apache.org; pa...@asert.com.au
> Sub
his or .with(returnThis:true), or the equally
cryptic .with(true).
Jason Winnebeck
-Original Message-
From: Philip Mitchell [mailto:pjmitch...@blueyonder.co.uk]
Sent: Tuesday, November 08, 2016 7:53 PM
To: users@groovy.apache.org; pa...@asert.com.au
Subject: Re: .with() variant that retu
What about a syntax for closures that return 'this' implicitly?
On Wed, Nov 9, 2016 at 2:57 AM, o...@ocs.cz wrote:
> Paul,
>
> > On 9. 11. 2016, at 2:43 AM, Paul King wrote:
> > Everything you say is true but withThis() has some subtle issues.
> > It would be a fine name for the current with()
Paul,
> On 9. 11. 2016, at 2:43 AM, Paul King wrote:
> Everything you say is true but withThis() has some subtle issues.
> It would be a fine name for the current with() method, so it's hard to
> distinguish between the two.
That's why I have suggested to part with the original one (but for back
Hi Phil,
Everything you say is true but withThis() has some subtle issues.
It would be a fine name for the current with() method, so it's hard to
distinguish between the two.
Using self.with(closure) sets self to be the delegate of the closure
which effectively means it becomes the "implicit this"
+1 for withThis()
-1 tap()
I agree with the point below. Given this is virtually identical to the existing
with() method, the new methods name should reflect that. Consistency within
Groovy and it’s existing libraries counts for more than consistency with what
the method is called in another la
Well we certainly could have as per Jochen's suggestion a DGM method
roughly like:
public static with(def self, boolean returnThis, Closure closure) { ... }
and for backwards compatibility returnThis would default to false,
i.e. with(closure) and identity(closure) are an alias for with(false, clo
+1 for withThis or withValue and +10 for Jochen's overloading proposal
if it's feasible.
-1000 for tap. Completely nonsensical to me and makes me think of
network tun/tap interfaces in Linux or something like that. Isn't the
functionality a little bit like the Builder pattern more than a pipelin
Some really neat and creative suggestions here suddenly. Still happy with
any name, but I do like "withThis" and "having", However, tap seems to be
gaining momentum and with good reasons, despite the common complaint of
"What the heck does tap mean". I agree it makes more sense after
explained.
+1 for tap. Concise and makes sense once explained (even intuitive to some).
Have you ever tried to find usages of with in groovy with code examples with
google without eventually loosing your temper ?
For one thing, I think tap will be easier to google for.
Marc Paquette
> Le 8 nov. 2016 à
> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou wrote:
>
> what about an overloaded with:
+1
Or even something like:
myObject.with { ... } // current behaviour
myObject.with(return:this) { ... } // returns this when finished.
myObejct.with(return:new Object()) { ... } // returns a new Object
what about an overloaded with:
myObject.with(true) {
// some code
}
or:
myObject.with(returnThis:true) {
// some code
}
or... well I am sure there are many variants... just want to know if
something like this doesn't cut it.
bye Jochen
the input without changing it and allowing it to pass unimpeded, unlike a
>> filter or a function.
>>
>> Jason
>>
>> -Original Message-
>> From: Paul King [mailto:pa...@asert.com.au]
>> Sent: Tuesday, November 08, 2016 9:34 AM
>> To: users@gro
"tapping" a water pipe). A tap observes
> the input without changing it and allowing it to pass unimpeded, unlike a
> filter or a function.
>
> Jason
>
> -Original Message-
> From: Paul King [mailto:pa...@asert.com.au]
> Sent: Tuesday, November 08, 2016 9:3
e-
From: Paul King [mailto:pa...@asert.com.au]
Sent: Tuesday, November 08, 2016 9:34 AM
To: users@groovy.apache.org
Subject: .with() variant that returns the original object
Hi everyone,
We are hoping to release 2.5 not too far down the track. We are working on a
revamped release process that is go
P.S. Perhaps "resultWith" or "resultTapping" would be even better than
"valueXXX".
On 8. 11. 2016, at 16:15, OC wrote:
> Hi there,
>
> as always I can be wrong, but I do not think it is possible to find a good
> name which (a) expresses the behaviour well (b) along with its very close
> simi
Hi there,
as always I can be wrong, but I do not think it is possible to find a good name
which (a) expresses the behaviour well (b) along with its very close similarity
to 'with', which is a problem of 'tap's etc can be found.
Therefore myself, I would advocate for
(a) **renaming current 'wit
Yes, that's a problem but "tap" means nothing to me so I need to consult
docs to understand code with "tap".
On 8 November 2016 at 15:09, Guillaume Laforge wrote:
> "having" makes me think too much of SQL, so it might be a bit misleading?
>
> On Tue, Nov 8, 2016 at 4:01 PM, Krzysztof Kowalczyk <
"having" makes me think too much of SQL, so it might be a bit misleading?
On Tue, Nov 8, 2016 at 4:01 PM, Krzysztof Kowalczyk <
kowalczyk.krzysz...@gmail.com> wrote:
> Hi,
>
> What about "having":
>
> house.having {
> windows.open()
> }.having{
> doors.locked()
> }
>
> car.having { wheels.hav
Hi,
What about "having":
house.having {
windows.open()
}.having{
doors.locked()
}
car.having { wheels.having{ screws.allInPlace = true }}
I guess withThis could be an alias (maybe even deprecated) so people would
be able to find other method when they notice that returning this is silly.
R
+1 for tap.
Alternatives don't seem to fit well.
My proposal is touch.
Example:
assert [:].touch {
a = 1
}.touch {
b = 2
} == [a:1, b:2]
If you start touching the object, it is rather intuitive that you get
the object itself as a result :)
Cheers,
Kostas
PS: Some guys here may als
I guess I should have listed my thoughts. I was initially thinking
apply to match Kotlin but the functional programming conflict is
likely to be an issue down the track, so I am thinking tap or
autoWith.
On Wed, Nov 9, 2016 at 12:44 AM, Cédric Champeau
wrote:
> +1 to `tap`
>
> 2016-11-08 15:41 G
+1 to `tap`
2016-11-08 15:41 GMT+01:00 Guillaume Laforge :
> I quite like "tap" (like in wiretaping, you're looking through the pipe)
> We already have some rubyisms, so having one more is not a bad idea at all
> for consistency.
>
> "doto" doesn't really help me understand what the method is abo
I quite like "tap" (like in wiretaping, you're looking through the pipe)
We already have some rubyisms, so having one more is not a bad idea at all
for consistency.
"doto" doesn't really help me understand what the method is about.
"apply" is too overloaded, for functional programming, etc, so I'
Hi everyone,
We are hoping to release 2.5 not too far down the track. We are
working on a revamped release process that is going to dramatically
improve our ability to release early/release often but also comply
with some additional Apache requirements that we follow these days.
But more on that a
41 matches
Mail list logo
