Re: .with() variant that returns the original object

[o...@ocs.cz]

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 backward 
compatibility) and take two new methods,

foo.doWith { ... } // which returns foo, which seems sorta logical
foo.resultWith { ... } // which returns the result of the closure and is worlds 
more intuitive that the original one

or am I overlooking something of importance?

All the best,
OC

> Using self.with(closure) sets self to be the delegate of the closure
> which effectively means it becomes the "implicit this" object.
> So conceptually a shorthand for self.withSelfAsTheImplicitThisObject(closure).
> The new method needs to be a shorthand for
> self.withSelfAsTheImplicitThisObjectThenReturningSelf(closure).
> So when picking the shorthand, we should derive something about the
> dirrerence between these two names in the shortcut and "This" is one
> of the similarities.
> I'd prefer "withThen".
> 
> Also, the link with tap and Ruby isn't about trying to be like Ruby
> but about not introducing yet another name for something that is in
> use elsewhere *unless* we have a good reason.
> 
> Cheers, Paul.
> 
> On Wed, Nov 9, 2016 at 10:53 AM, Philip Mitchell
>  wrote:
>> +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 language.
>> 
>> I see comments below that tap() makes more sense once explained, but I would 
>> argue that the fact it needs explained is enough of a reason to reject it. I 
>> lean toward method names that clearly express what they do. tap() seem 
>> cryptic. The name withThis() has the virtue of being reasonably descriptive 
>> as well as being consistent with the existing with() method name.
>> 
>> Just my 2-cents worth.
>> 
>> Phil Mitchell

Re: .with() variant that returns the original object

[Paul King]

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, closure)
and tap would be an alias for with(true, closure)

I think it is worth having the alias, if nothing else for better type
inferencing we'll get from the signatures but also letting people
choose between tap and with(true).

Cheers, Paul.


On Wed, Nov 9, 2016 at 9:02 AM, Henrik Martin  wrote:
> +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 pipeline of commands?
> Maybe I'm misunderstanding the whole thing. Either way, to introduce a
> completely new name for something that is already named and simply augmented
> in terms of functionality seems very confusing and counter intuitive to me.
> Imagine a Groovy newbie that reads a tutorial or reference manual and first
> learns about with(). Then a little further on, tap() is introduced. I would
> immediately think "why on earth did they name these things completely
> differently, when one is essentially a variant of the other???". Again,
> forgive me if I'm completely misunderstanding the context here.
>
> -Henrik
>
> On 11/8/16 10:16 AM, Gerald Wiltse wrote:
>
> 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.
>
> Gerald R. Wiltse
> jerrywil...@gmail.com
>
>
> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette  wrote:
>>
>> +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 à 12:32, Suderman Keith  a écrit :
>>
>>
>> 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 when
>> finished.
>>
>> This particular syntax would take a bit of extra parser arm waving since
>> the `return` keyword is being used differently in this context.
>>
>> Keith
>>
>>
>> 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
>>
>>
>>
>
>

Re: .with() variant that returns the original object

[Henrik Martin]

+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 pipeline 
of commands? Maybe I'm misunderstanding the whole thing. Either way, to 
introduce a completely new name for something that is already named and 
simply augmented in terms of functionality seems very confusing and 
counter intuitive to me. Imagine a Groovy newbie that reads a tutorial 
or reference manual and first learns about with(). Then a little further 
on, tap() is introduced. I would immediately think "why on earth did 
they name these things completely differently, when one is essentially a 
variant of the other???". Again, forgive me if I'm completely 
misunderstanding the context here.


-Henrik

On 11/8/16 10:16 AM, Gerald Wiltse wrote:
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.


Gerald R. Wiltse
jerrywil...@gmail.com 


On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette > wrote:


+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 à 12:32, Suderman Keith > a écrit :



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 when finished.

This particular syntax would take a bit of extra parser arm
waving since the `return` keyword is being used differently in
this context.

Keith




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

Re: .with() variant that returns the original object

[Marc Paquette]

+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 à 12:32, Suderman Keith  a écrit :
> 
> 
>> 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 when 
> finished.
> 
> This particular syntax would take a bit of extra parser arm waving since the 
> `return` keyword is being used differently in this context.
> 
> Keith
> 
>> 
 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
> 

Re: .with() variant that returns the original object

[Suderman Keith]

> 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 when 
finished.

This particular syntax would take a bit of extra parser arm waving since the 
`return` keyword is being used differently in this context.

Keith

> 
>>> 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

Using Groovy in Business Intelligence applications via dyna4JDBC driver

[Péter Gergely Horváth]

Hi Groovy Users,

There is one more area where the power of Groovy can now be utilized: I
developed a JDBC driver called dyna4JDBC (http://dyna4jdbc.org/), which
allows Groovy (or any JSR-223 compatible scripting language) to be called
via the JDBC API. The standard output echoed by the script is parsed to a
JDBC Result Set, so that the caller application can process it further.

The goal of this driver was to allow JDBC-compatible reporting and ETL
applications calling dynamic JVM language scripts as if they were databases
and exposing the script output as a result set for further processing
(e.g.: advanced visualizations: charts etc.)

For example, you can now use Eclipse BIRT [1] reporting application and
create reports, which are backed by a Groovy script: You can simply
configure a JDBC datasource in Eclipse BIRT and write a Groovy script
against that datasource instead of SQL. The output the script prints to the
standard output will appear as the result set of the "query".

You can get a quick introduction on the project home page [2]. The
documentation is on GitHub Wiki [3], and the binary version of the driver
can be downloaded from GitHub [4] or from Maven Central [5].

I am sharing it here in the hope that it might be useful for some people
and that I could potentially get some feedback you. :)

Cheers,
Peter

[1] http://www.eclipse.org/birt/
[2] http://dyna4jdbc.org/
[3] https://github.com/peter-gergely-horvath/dyna4jdbc/wiki
[4] https://github.com/peter-gergely-horvath/dyna4jdbc/releases
[5] http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.
github.peter-gergely-horvath%22%20a%3A%22dyna4jdbc%22

Re: .with() variant that returns the original object

[Suderman Keith]

+1 for withThis

withThis{} indicates it is just another form of the .with{} method that returns 
this, that seems the most logical and consistent name.  The name `tap` strikes 
me as non-sensical; what does doing something "with" an object have to do with 
tapping a beer keg or wire tapping a phone line?

My two cents.
Keith

> On Nov 8, 2016, at 10:20 AM, Winnebeck, Jason 
>  wrote:
> 
> Normally, I'd say that we should use Java as first inspiration and all other 
> popular JVM languages (including Kotlin) as second inspiration, because it's 
> really nice as a JVM-ecosystem developer to have a common set of terminology 
> and methods. However, I agree with Paul's analysis. The meaning of "apply" 
> conflicts with Java's Function.apply as well as apply from JavaScript world 
> (I don't know if others agree but I think of Groovy in a similar mindset to 
> JS). The closest Java signature is Function.identity, but identity is already 
> used in Groovy and most think of identity function as "doing nothing".
> 
> Therefore, my vote is for tap. When I see tap it makes sense to me. It makes 
> me think of the Unix "tee" shell command that does the same thing by sending 
> the object to another command and returning the same output unmodified. The 
> usage of tap here is also consistent with network terminology (a network 
> tap), and real-world usage (such as "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: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 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 another time.
> 
> One outstanding feature request targeted for potential inclusion in
> 2.5 is an alternative to .with{} that automatically returns the original 
> object after executing the closure - recall that .with{} returns the last 
> evaluated expression. The proposal is here:
> 
> https://github.com/apache/groovy/pull/174/files
> 
> We can't use the old name since that would break backward compatibility and 
> is of utility in its current form in any case, so we are looking for a new 
> name for the proposed method. If you look at the PR you will see it has been 
> called 'tap' and 'doto' and numerous other names have been suggested. We 
> regard naming as very important and normally we'd have very strong views 
> about suitable names based on functionality and similar method names within 
> the Groovy codebase. But in this instance, an obvious name hasn't popped out 
> at us, so we are requesting feedback from the community about what names make 
> most sense to you.
> 
> Firstly, here is what the method does. I'll use 'tap' in these examples since 
> that is what the PR currently uses but we can easily change that based on 
> feedback.
> 
> myObject.tap {
>// some code
> }
> 
> is equivalent to:
> 
> myObject.with {
>// some code
>return this
> }
> 
> Returning the 'self' object lends itself to various kinds of chaining, e.g.
> 
> assert [:].tap {
>a = 1
> }.tap {
>b = 2
> } == [a:1, b:2]
> 
> Or this one (adapted from a blog post[1] - and assuming you have a 
> config.properties file containing answer=42 as one of the properties):
> 
> assert new Properties().tap {
>new FileInputStream('config.properties').withCloseable {
>load(it)
>}
> }.answer == '42'
> 
> Here are some of the names that have been suggested with some commentary:
> 
> dotoUsed by Clojure. Not camel case as per normal convention
> (though we have upto and downto which also break that convention) and it 
> isn't immediately obvious which is which between with and doto just from the 
> names
> 
> tapComes from Ruby and a previous Groovy extension outside core
> exists; meant to conjure up the idea of tapping into an object
> 
> autoWithSame as with but automatically returns self
> 
> doWith   Again, hard to distinguish between doWith and with from the
> names themselves
> 
> teeAn alternative name for tap
> 
> autoA shortened version of 'autoWith'
> 
> applysame as Kotlin which has copied Groovy's with but suffers
> from the downside that apply is already heavily overleaded in other contexts, 
> e.g. functional programming
> 
> withThisDistinction with normal with a bit subtle perhaps
> 
> asThisDitto
> 
> withinDitto
> 
> I'll also point out the 'identity' is currently an alias for 'with', in case 
> that provides any additional inspiration.
> 
> Perhaps you dis/like one of the above or have some other 

Re: .with() variant that returns the original object

[OC]

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 'with'** (keeping, of course, the original name as an 
equivalent for backward compatibility; just by convention discourage its use in 
new code)
(b) and adding an appropriate variant of the name for the new functionality.

Myself, I would probably like

- 'doWith' for the new one -- considering returning 'this' a reasonable 
default, which it is
- 'valueWith' as a modern equivalent of 'with' for the old functionality

or perhaps

- 'tap' for the new one (for all the reasons others expressed in favour of the 
name)
- 'valueTapping' as a modern equivalent of 'with' for the old functionality

or something like that.

All the best,
OC


On 8. 11. 2016, at 15:34, Paul King  wrote:

> 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 another time.
> 
> One outstanding feature request targeted for potential inclusion in
> 2.5 is an alternative to .with{} that automatically returns the
> original object after executing the closure - recall that .with{}
> returns the last evaluated expression. The proposal is here:
> 
> https://github.com/apache/groovy/pull/174/files
> 
> We can't use the old name since that would break backward
> compatibility and is of utility in its current form in any case, so we
> are looking for a new name for the proposed method. If you look at the
> PR you will see it has been called 'tap' and 'doto' and numerous other
> names have been suggested. We regard naming as very important and
> normally we'd have very strong views about suitable names based on
> functionality and similar method names within the Groovy codebase. But
> in this instance, an obvious name hasn't popped out at us, so we are
> requesting feedback from the community about what names make most
> sense to you.
> 
> Firstly, here is what the method does. I'll use 'tap' in these
> examples since that is what the PR currently uses but we can easily
> change that based on feedback.
> 
> myObject.tap {
>// some code
> }
> 
> is equivalent to:
> 
> myObject.with {
>// some code
>return this
> }
> 
> Returning the 'self' object lends itself to various kinds of chaining, e.g.
> 
> assert [:].tap {
>a = 1
> }.tap {
>b = 2
> } == [a:1, b:2]
> 
> Or this one (adapted from a blog post[1] - and assuming you have a
> config.properties file containing answer=42 as one of the properties):
> 
> assert new Properties().tap {
>new FileInputStream('config.properties').withCloseable {
>load(it)
>}
> }.answer == '42'
> 
> Here are some of the names that have been suggested with some commentary:
> 
> dotoUsed by Clojure. Not camel case as per normal convention
> (though we have upto and downto which also break that convention) and
> it isn't immediately obvious which is which between with and doto just
> from the names
> 
> tapComes from Ruby and a previous Groovy extension outside core
> exists; meant to conjure up the idea of tapping into an object
> 
> autoWithSame as with but automatically returns self
> 
> doWith   Again, hard to distinguish between doWith and with from the
> names themselves
> 
> teeAn alternative name for tap
> 
> autoA shortened version of 'autoWith'
> 
> applysame as Kotlin which has copied Groovy's with but suffers
> from the downside that apply is already heavily overleaded in other
> contexts, e.g. functional programming
> 
> withThisDistinction with normal with a bit subtle perhaps
> 
> asThisDitto
> 
> withinDitto
> 
> I'll also point out the 'identity' is currently an alias for 'with',
> in case that provides any additional inspiration.
> 
> Perhaps you dis/like one of the above or have some other suggestions.
> Let us know.
> 
> 
> Cheers, Paul.
> 
> 
> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/

Re: .with() variant that returns the original object

[Krzysztof Kowalczyk]

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 <
> kowalczyk.krzysz...@gmail.com> wrote:
>
>> 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.
>>
>> Regards,
>> Krzysztof
>>
>> On 8 November 2016 at 14:53, Kostas Saidis  wrote:
>>
>>> +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 also like avec, perhaps?
>>>
>>>
>>>
>>> On 8/11/2016 4:34 μμ, Paul King wrote:
>>>
 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 another time.

 One outstanding feature request targeted for potential inclusion in
 2.5 is an alternative to .with{} that automatically returns the
 original object after executing the closure - recall that .with{}
 returns the last evaluated expression. The proposal is here:

 https://github.com/apache/groovy/pull/174/files

 We can't use the old name since that would break backward
 compatibility and is of utility in its current form in any case, so we
 are looking for a new name for the proposed method. If you look at the
 PR you will see it has been called 'tap' and 'doto' and numerous other
 names have been suggested. We regard naming as very important and
 normally we'd have very strong views about suitable names based on
 functionality and similar method names within the Groovy codebase. But
 in this instance, an obvious name hasn't popped out at us, so we are
 requesting feedback from the community about what names make most
 sense to you.

 Firstly, here is what the method does. I'll use 'tap' in these
 examples since that is what the PR currently uses but we can easily
 change that based on feedback.

 myObject.tap {
  // some code
 }

 is equivalent to:

 myObject.with {
  // some code
  return this
 }

 Returning the 'self' object lends itself to various kinds of chaining,
 e.g.

 assert [:].tap {
  a = 1
 }.tap {
  b = 2
 } == [a:1, b:2]

 Or this one (adapted from a blog post[1] - and assuming you have a
 config.properties file containing answer=42 as one of the properties):

 assert new Properties().tap {
  new FileInputStream('config.properties').withCloseable {
  load(it)
  }
 }.answer == '42'

 Here are some of the names that have been suggested with some
 commentary:

 dotoUsed by Clojure. Not camel case as per normal convention
 (though we have upto and downto which also break that convention) and
 it isn't immediately obvious which is which between with and doto just
 from the names

 tapComes from Ruby and a previous Groovy extension outside core
 exists; meant to conjure up the idea of tapping into an object

 autoWithSame as with but automatically returns self

 doWith   Again, hard to distinguish between doWith and with from the
 names themselves

 teeAn alternative name for tap

 autoA shortened version of 'autoWith'

 applysame as Kotlin which has copied Groovy's with but suffers
 from the downside that apply is already heavily overleaded in other
 contexts, e.g. functional programming

 withThisDistinction with normal with a bit subtle perhaps

 asThisDitto

 withinDitto

 I'll also point out the 'identity' is currently an alias for 'with',
 in case that provides any additional inspiration.

 Perhaps you dis/like one of the above or have some other suggestions.
 Let us know.


 Cheers, Paul.


 [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan
 dard-library/


>>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer 

Re: .with() variant that returns the original object

[Krzysztof Kowalczyk]

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.

Regards,
Krzysztof

On 8 November 2016 at 14:53, Kostas Saidis  wrote:

> +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 also like avec, perhaps?
>
>
>
> On 8/11/2016 4:34 μμ, Paul King wrote:
>
>> 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 another time.
>>
>> One outstanding feature request targeted for potential inclusion in
>> 2.5 is an alternative to .with{} that automatically returns the
>> original object after executing the closure - recall that .with{}
>> returns the last evaluated expression. The proposal is here:
>>
>> https://github.com/apache/groovy/pull/174/files
>>
>> We can't use the old name since that would break backward
>> compatibility and is of utility in its current form in any case, so we
>> are looking for a new name for the proposed method. If you look at the
>> PR you will see it has been called 'tap' and 'doto' and numerous other
>> names have been suggested. We regard naming as very important and
>> normally we'd have very strong views about suitable names based on
>> functionality and similar method names within the Groovy codebase. But
>> in this instance, an obvious name hasn't popped out at us, so we are
>> requesting feedback from the community about what names make most
>> sense to you.
>>
>> Firstly, here is what the method does. I'll use 'tap' in these
>> examples since that is what the PR currently uses but we can easily
>> change that based on feedback.
>>
>> myObject.tap {
>>  // some code
>> }
>>
>> is equivalent to:
>>
>> myObject.with {
>>  // some code
>>  return this
>> }
>>
>> Returning the 'self' object lends itself to various kinds of chaining,
>> e.g.
>>
>> assert [:].tap {
>>  a = 1
>> }.tap {
>>  b = 2
>> } == [a:1, b:2]
>>
>> Or this one (adapted from a blog post[1] - and assuming you have a
>> config.properties file containing answer=42 as one of the properties):
>>
>> assert new Properties().tap {
>>  new FileInputStream('config.properties').withCloseable {
>>  load(it)
>>  }
>> }.answer == '42'
>>
>> Here are some of the names that have been suggested with some commentary:
>>
>> dotoUsed by Clojure. Not camel case as per normal convention
>> (though we have upto and downto which also break that convention) and
>> it isn't immediately obvious which is which between with and doto just
>> from the names
>>
>> tapComes from Ruby and a previous Groovy extension outside core
>> exists; meant to conjure up the idea of tapping into an object
>>
>> autoWithSame as with but automatically returns self
>>
>> doWith   Again, hard to distinguish between doWith and with from the
>> names themselves
>>
>> teeAn alternative name for tap
>>
>> autoA shortened version of 'autoWith'
>>
>> applysame as Kotlin which has copied Groovy's with but suffers
>> from the downside that apply is already heavily overleaded in other
>> contexts, e.g. functional programming
>>
>> withThisDistinction with normal with a bit subtle perhaps
>>
>> asThisDitto
>>
>> withinDitto
>>
>> I'll also point out the 'identity' is currently an alias for 'with',
>> in case that provides any additional inspiration.
>>
>> Perhaps you dis/like one of the above or have some other suggestions.
>> Let us know.
>>
>>
>> Cheers, Paul.
>>
>>
>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan
>> dard-library/
>>
>>
>

Re: .with() variant that returns the original object

[Kostas Saidis]

+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 also like avec, perhaps?


On 8/11/2016 4:34 μμ, Paul King wrote:

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 another time.

One outstanding feature request targeted for potential inclusion in
2.5 is an alternative to .with{} that automatically returns the
original object after executing the closure - recall that .with{}
returns the last evaluated expression. The proposal is here:

https://github.com/apache/groovy/pull/174/files

We can't use the old name since that would break backward
compatibility and is of utility in its current form in any case, so we
are looking for a new name for the proposed method. If you look at the
PR you will see it has been called 'tap' and 'doto' and numerous other
names have been suggested. We regard naming as very important and
normally we'd have very strong views about suitable names based on
functionality and similar method names within the Groovy codebase. But
in this instance, an obvious name hasn't popped out at us, so we are
requesting feedback from the community about what names make most
sense to you.

Firstly, here is what the method does. I'll use 'tap' in these
examples since that is what the PR currently uses but we can easily
change that based on feedback.

myObject.tap {
 // some code
}

is equivalent to:

myObject.with {
 // some code
 return this
}

Returning the 'self' object lends itself to various kinds of chaining, e.g.

assert [:].tap {
 a = 1
}.tap {
 b = 2
} == [a:1, b:2]

Or this one (adapted from a blog post[1] - and assuming you have a
config.properties file containing answer=42 as one of the properties):

assert new Properties().tap {
 new FileInputStream('config.properties').withCloseable {
 load(it)
 }
}.answer == '42'

Here are some of the names that have been suggested with some commentary:

dotoUsed by Clojure. Not camel case as per normal convention
(though we have upto and downto which also break that convention) and
it isn't immediately obvious which is which between with and doto just
from the names

tapComes from Ruby and a previous Groovy extension outside core
exists; meant to conjure up the idea of tapping into an object

autoWithSame as with but automatically returns self

doWith   Again, hard to distinguish between doWith and with from the
names themselves

teeAn alternative name for tap

autoA shortened version of 'autoWith'

applysame as Kotlin which has copied Groovy's with but suffers
from the downside that apply is already heavily overleaded in other
contexts, e.g. functional programming

withThisDistinction with normal with a bit subtle perhaps

asThisDitto

withinDitto

I'll also point out the 'identity' is currently an alias for 'with',
in case that provides any additional inspiration.

Perhaps you dis/like one of the above or have some other suggestions.
Let us know.


Cheers, Paul.


[1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/

Re: .with() variant that returns the original object

[Paul King]

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 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 about.
>>
>> "apply" is too overloaded, for functional programming, etc, so I'd really
>> avoid it.
>>
>> "tee" why not, but I didn't really knew what it was meanting.
>>
>> Not a big fan of auto, asThis, withThis or within.
>>
>> My preference clearly goes for tap!
>>
>> On Tue, Nov 8, 2016 at 3:34 PM, Paul King  wrote:
>>>
>>> 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 another time.
>>>
>>> One outstanding feature request targeted for potential inclusion in
>>> 2.5 is an alternative to .with{} that automatically returns the
>>> original object after executing the closure - recall that .with{}
>>> returns the last evaluated expression. The proposal is here:
>>>
>>> https://github.com/apache/groovy/pull/174/files
>>>
>>> We can't use the old name since that would break backward
>>> compatibility and is of utility in its current form in any case, so we
>>> are looking for a new name for the proposed method. If you look at the
>>> PR you will see it has been called 'tap' and 'doto' and numerous other
>>> names have been suggested. We regard naming as very important and
>>> normally we'd have very strong views about suitable names based on
>>> functionality and similar method names within the Groovy codebase. But
>>> in this instance, an obvious name hasn't popped out at us, so we are
>>> requesting feedback from the community about what names make most
>>> sense to you.
>>>
>>> Firstly, here is what the method does. I'll use 'tap' in these
>>> examples since that is what the PR currently uses but we can easily
>>> change that based on feedback.
>>>
>>> myObject.tap {
>>> // some code
>>> }
>>>
>>> is equivalent to:
>>>
>>> myObject.with {
>>> // some code
>>> return this
>>> }
>>>
>>> Returning the 'self' object lends itself to various kinds of chaining,
>>> e.g.
>>>
>>> assert [:].tap {
>>> a = 1
>>> }.tap {
>>> b = 2
>>> } == [a:1, b:2]
>>>
>>> Or this one (adapted from a blog post[1] - and assuming you have a
>>> config.properties file containing answer=42 as one of the properties):
>>>
>>> assert new Properties().tap {
>>> new FileInputStream('config.properties').withCloseable {
>>> load(it)
>>> }
>>> }.answer == '42'
>>>
>>> Here are some of the names that have been suggested with some commentary:
>>>
>>> dotoUsed by Clojure. Not camel case as per normal convention
>>> (though we have upto and downto which also break that convention) and
>>> it isn't immediately obvious which is which between with and doto just
>>> from the names
>>>
>>> tapComes from Ruby and a previous Groovy extension outside core
>>> exists; meant to conjure up the idea of tapping into an object
>>>
>>> autoWithSame as with but automatically returns self
>>>
>>> doWith   Again, hard to distinguish between doWith and with from the
>>> names themselves
>>>
>>> teeAn alternative name for tap
>>>
>>> autoA shortened version of 'autoWith'
>>>
>>> applysame as Kotlin which has copied Groovy's with but suffers
>>> from the downside that apply is already heavily overleaded in other
>>> contexts, e.g. functional programming
>>>
>>> withThisDistinction with normal with a bit subtle perhaps
>>>
>>> asThisDitto
>>>
>>> withinDitto
>>>
>>> I'll also point out the 'identity' is currently an alias for 'with',
>>> in case that provides any additional inspiration.
>>>
>>> Perhaps you dis/like one of the above or have some other suggestions.
>>> Let us know.
>>>
>>>
>>> Cheers, Paul.
>>>
>>>
>>> [1]
>>> http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge / Google+
>
>

Re: .with() variant that returns the original object

[Cédric Champeau]

+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 about.
>
> "apply" is too overloaded, for functional programming, etc, so I'd really
> avoid it.
>
> "tee" why not, but I didn't really knew what it was meanting.
>
> Not a big fan of auto, asThis, withThis or within.
>
> My preference clearly goes for tap!
>
> On Tue, Nov 8, 2016 at 3:34 PM, Paul King  wrote:
>
>> 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 another time.
>>
>> One outstanding feature request targeted for potential inclusion in
>> 2.5 is an alternative to .with{} that automatically returns the
>> original object after executing the closure - recall that .with{}
>> returns the last evaluated expression. The proposal is here:
>>
>> https://github.com/apache/groovy/pull/174/files
>>
>> We can't use the old name since that would break backward
>> compatibility and is of utility in its current form in any case, so we
>> are looking for a new name for the proposed method. If you look at the
>> PR you will see it has been called 'tap' and 'doto' and numerous other
>> names have been suggested. We regard naming as very important and
>> normally we'd have very strong views about suitable names based on
>> functionality and similar method names within the Groovy codebase. But
>> in this instance, an obvious name hasn't popped out at us, so we are
>> requesting feedback from the community about what names make most
>> sense to you.
>>
>> Firstly, here is what the method does. I'll use 'tap' in these
>> examples since that is what the PR currently uses but we can easily
>> change that based on feedback.
>>
>> myObject.tap {
>> // some code
>> }
>>
>> is equivalent to:
>>
>> myObject.with {
>> // some code
>> return this
>> }
>>
>> Returning the 'self' object lends itself to various kinds of chaining,
>> e.g.
>>
>> assert [:].tap {
>> a = 1
>> }.tap {
>> b = 2
>> } == [a:1, b:2]
>>
>> Or this one (adapted from a blog post[1] - and assuming you have a
>> config.properties file containing answer=42 as one of the properties):
>>
>> assert new Properties().tap {
>> new FileInputStream('config.properties').withCloseable {
>> load(it)
>> }
>> }.answer == '42'
>>
>> Here are some of the names that have been suggested with some commentary:
>>
>> dotoUsed by Clojure. Not camel case as per normal convention
>> (though we have upto and downto which also break that convention) and
>> it isn't immediately obvious which is which between with and doto just
>> from the names
>>
>> tapComes from Ruby and a previous Groovy extension outside core
>> exists; meant to conjure up the idea of tapping into an object
>>
>> autoWithSame as with but automatically returns self
>>
>> doWith   Again, hard to distinguish between doWith and with from the
>> names themselves
>>
>> teeAn alternative name for tap
>>
>> autoA shortened version of 'autoWith'
>>
>> applysame as Kotlin which has copied Groovy's with but suffers
>> from the downside that apply is already heavily overleaded in other
>> contexts, e.g. functional programming
>>
>> withThisDistinction with normal with a bit subtle perhaps
>>
>> asThisDitto
>>
>> withinDitto
>>
>> I'll also point out the 'identity' is currently an alias for 'with',
>> in case that provides any additional inspiration.
>>
>> Perhaps you dis/like one of the above or have some other suggestions.
>> Let us know.
>>
>>
>> Cheers, Paul.
>>
>>
>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan
>> dard-library/
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: .with() variant that returns the original object

[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 about.

"apply" is too overloaded, for functional programming, etc, so I'd really
avoid it.

"tee" why not, but I didn't really knew what it was meanting.

Not a big fan of auto, asThis, withThis or within.

My preference clearly goes for tap!

On Tue, Nov 8, 2016 at 3:34 PM, Paul King  wrote:

> 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 another time.
>
> One outstanding feature request targeted for potential inclusion in
> 2.5 is an alternative to .with{} that automatically returns the
> original object after executing the closure - recall that .with{}
> returns the last evaluated expression. The proposal is here:
>
> https://github.com/apache/groovy/pull/174/files
>
> We can't use the old name since that would break backward
> compatibility and is of utility in its current form in any case, so we
> are looking for a new name for the proposed method. If you look at the
> PR you will see it has been called 'tap' and 'doto' and numerous other
> names have been suggested. We regard naming as very important and
> normally we'd have very strong views about suitable names based on
> functionality and similar method names within the Groovy codebase. But
> in this instance, an obvious name hasn't popped out at us, so we are
> requesting feedback from the community about what names make most
> sense to you.
>
> Firstly, here is what the method does. I'll use 'tap' in these
> examples since that is what the PR currently uses but we can easily
> change that based on feedback.
>
> myObject.tap {
> // some code
> }
>
> is equivalent to:
>
> myObject.with {
> // some code
> return this
> }
>
> Returning the 'self' object lends itself to various kinds of chaining, e.g.
>
> assert [:].tap {
> a = 1
> }.tap {
> b = 2
> } == [a:1, b:2]
>
> Or this one (adapted from a blog post[1] - and assuming you have a
> config.properties file containing answer=42 as one of the properties):
>
> assert new Properties().tap {
> new FileInputStream('config.properties').withCloseable {
> load(it)
> }
> }.answer == '42'
>
> Here are some of the names that have been suggested with some commentary:
>
> dotoUsed by Clojure. Not camel case as per normal convention
> (though we have upto and downto which also break that convention) and
> it isn't immediately obvious which is which between with and doto just
> from the names
>
> tapComes from Ruby and a previous Groovy extension outside core
> exists; meant to conjure up the idea of tapping into an object
>
> autoWithSame as with but automatically returns self
>
> doWith   Again, hard to distinguish between doWith and with from the
> names themselves
>
> teeAn alternative name for tap
>
> autoA shortened version of 'autoWith'
>
> applysame as Kotlin which has copied Groovy's with but suffers
> from the downside that apply is already heavily overleaded in other
> contexts, e.g. functional programming
>
> withThisDistinction with normal with a bit subtle perhaps
>
> asThisDitto
>
> withinDitto
>
> I'll also point out the 'identity' is currently an alias for 'with',
> in case that provides any additional inspiration.
>
> Perhaps you dis/like one of the above or have some other suggestions.
> Let us know.
>
>
> Cheers, Paul.
>
>
> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-
> standard-library/
>



-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

.with() variant that returns the original object

[Paul King]

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 another time.

One outstanding feature request targeted for potential inclusion in
2.5 is an alternative to .with{} that automatically returns the
original object after executing the closure - recall that .with{}
returns the last evaluated expression. The proposal is here:

https://github.com/apache/groovy/pull/174/files

We can't use the old name since that would break backward
compatibility and is of utility in its current form in any case, so we
are looking for a new name for the proposed method. If you look at the
PR you will see it has been called 'tap' and 'doto' and numerous other
names have been suggested. We regard naming as very important and
normally we'd have very strong views about suitable names based on
functionality and similar method names within the Groovy codebase. But
in this instance, an obvious name hasn't popped out at us, so we are
requesting feedback from the community about what names make most
sense to you.

Firstly, here is what the method does. I'll use 'tap' in these
examples since that is what the PR currently uses but we can easily
change that based on feedback.

myObject.tap {
// some code
}

is equivalent to:

myObject.with {
// some code
return this
}

Returning the 'self' object lends itself to various kinds of chaining, e.g.

assert [:].tap {
a = 1
}.tap {
b = 2
} == [a:1, b:2]

Or this one (adapted from a blog post[1] - and assuming you have a
config.properties file containing answer=42 as one of the properties):

assert new Properties().tap {
new FileInputStream('config.properties').withCloseable {
load(it)
}
}.answer == '42'

Here are some of the names that have been suggested with some commentary:

dotoUsed by Clojure. Not camel case as per normal convention
(though we have upto and downto which also break that convention) and
it isn't immediately obvious which is which between with and doto just
from the names

tapComes from Ruby and a previous Groovy extension outside core
exists; meant to conjure up the idea of tapping into an object

autoWithSame as with but automatically returns self

doWith   Again, hard to distinguish between doWith and with from the
names themselves

teeAn alternative name for tap

autoA shortened version of 'autoWith'

applysame as Kotlin which has copied Groovy's with but suffers
from the downside that apply is already heavily overleaded in other
contexts, e.g. functional programming

withThisDistinction with normal with a bit subtle perhaps

asThisDitto

withinDitto

I'll also point out the 'identity' is currently an alias for 'with',
in case that provides any additional inspiration.

Perhaps you dis/like one of the above or have some other suggestions.
Let us know.


Cheers, Paul.


[1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/

Re: Closure does not see field when setting value

[Krzysztof Kowalczyk]

Jochen Theodorou wrote
> there we access the field only directly if [...]  an explicit this is
> used. 

So should prefixing it with "this" should change the behaviour? 
It does not:


​import groovy.transform.Field

@Field 
int x = 0  

a {
assert this.x == 0
this.x = 1 
assert this.x == 1
} 

assert x == 0 

def a(Closure c) { 
c() 
}  ​




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Closure-does-not-see-field-when-setting-value-tp5736534p5736543.html
Sent from the Groovy Users mailing list archive at Nabble.com.

Re: Possible to improve tuples

[Krzysztof Kowalczyk]

Hi Bienlein,

I think it could be done with AST, it shouldn't be hard to do it in naive
way, but would not be easy to do it right. If you want to go with list as
return type then you would need to find every occurence of this type of
assignment. So you would need global ast transformations that finds every
occurence of Declaration that contains ArgumentList and assignment which
resolve to list and rewrite it. Simplistic way would be to replace the whole
declaration with declaration for every variable as "Type variable =
list[index] as Type" and the type of declared variable. You would need to
assign the list to a variable first, otherwise you would call function many
times. This would not complain if the code makes no sense. You could check
that with more work. Other option would be to use map instead:
@Tupledef getTuple(){  if(a) [a:1]  else [b:2]}
The actual return type can be complex to get in general if there are many
flows with different return types. But Assuming there is only one return
type and we dealing with simple methods, then you could create an AST
transformation that change the return type of this method to some type, let
say Tuple_a_int_b_int, or just random name. But then it would used bit
differently:
def x = getTuple()println x.aprintln x.b
I'm just evaluating ast transformations on my own so I am not able to tell
how hard it would be in
practice.https://dzone.com/articles/groovy-ast-transformations

Regards,Krzysztof



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Possible-to-improve-tuples-tp5735822p5736542.html
Sent from the Groovy Users mailing list archive at Nabble.com.

Re: Closure does not see field when setting value

[Jochen Theodorou]

On 08.11.2016 13:43, Paul King wrote:

Jochen, indeed the Closure version goes through setProperty() but I
thought we made it work in methods:

import groovy.transform.Field

@Field
int x = 2

def a() {
assert x == 2
println x
x = 1
assert x == 1
println x
}

println x
binding.variables.remove('x')
a()
assert x == 1
println x
println binding.variables.x

but not closures?


if there is a field of name x, we do directly access the field for the 
implicit or explicit this unless it is an open block, there we 
access the field only directly if part of the Closure, or an explicit 
this is used. For property access that happens on something else... for 
example foo.x ... we also do always go through the MOP.


bye Jochen

Re: Closure does not see field when setting value

[Paul King]

Jochen, indeed the Closure version goes through setProperty() but I
thought we made it work in methods:

import groovy.transform.Field

@Field
int x = 2

def a() {
assert x == 2
println x
x = 1
assert x == 1
println x
}

println x
binding.variables.remove('x')
a()
assert x == 1
println x
println binding.variables.x

but not closures?

Cheers, Paul.


On Tue, Nov 8, 2016 at 10:04 PM, Jochen Theodorou  wrote:
>
>
> On 08.11.2016 12:19, Paul King wrote:
>>
>> I think that is probably a bug - but with reads and writes.
>
>
> not sure it is really a bug. @Field in a script may give the script a field,
> but it will also have:
>
>> public Object getProperty(String property) {
>> try {
>> return binding.getVariable(property);
>> } catch (MissingPropertyException e) {
>> return super.getProperty(property);
>> }
>> }
>>
>> public void setProperty(String property, Object newValue) {
>> if ("binding".equals(property))
>> setBinding((Binding) newValue);
>> else if("metaClass".equals(property))
>> setMetaClass((MetaClass)newValue);
>> else
>> binding.setVariable(property, newValue);
>> }
>
>
> So reading "x" in the open block will go through getProperty, where it will
> first try the binding and failing there use the "normal" getProperty which
> will deliver him the field value. Writing "x" will go through setProperty
> and there it will write into the binding, giving the field no chance.
>
> The intended usage of @Field was for an open block, to give it additional
> state, it just does not work as expected in a Script, unless you change the
> get/setProperty implementations or use a different base class
>
> bye Jochen

Re: Closure does not see field when setting value

[Jochen Theodorou]

On 08.11.2016 12:19, Paul King wrote:

I think that is probably a bug - but with reads and writes.


not sure it is really a bug. @Field in a script may give the script a 
field, but it will also have:



public Object getProperty(String property) {
try {
return binding.getVariable(property);
} catch (MissingPropertyException e) {
return super.getProperty(property);
}
}

public void setProperty(String property, Object newValue) {
if ("binding".equals(property))
setBinding((Binding) newValue);
else if("metaClass".equals(property))
setMetaClass((MetaClass)newValue);
else
binding.setVariable(property, newValue);
}


So reading "x" in the open block will go through getProperty, where it 
will first try the binding and failing there use the "normal" 
getProperty which will deliver him the field value. Writing "x" will go 
through setProperty and there it will write into the binding, giving the 
field no chance.


The intended usage of @Field was for an open block, to give it 
additional state, it just does not work as expected in a Script, unless 
you change the get/setProperty implementations or use a different base class


bye Jochen

Re: Closure does not see field when setting value

[Krzysztof Kowalczyk]

Sorry I don't understand what you mean?





--
View this message in context: 
http://groovy.329449.n5.nabble.com/Closure-does-not-see-field-when-setting-value-tp5736534p5736536.html
Sent from the Groovy Users mailing list archive at Nabble.com.

Re: Closure does not see field when setting value

[Paul King]

I think that is probably a bug - but with reads and writes. Change
your declaration to "int x = 2" and see what you get?

Cheers, Paul.


On Tue, Nov 8, 2016 at 8:54 PM, Krzysztof Kowalczyk
 wrote:
> Hi,
> Today I was quite confused by behaviour of fields inside of closures. When I
> read a field value it is visible, but when I try to set it, it is not set,
> but a binding is set and then available for rest of the closure. This is
> rather confusing, can I disable such behaviour in any way?
>
> import groovy.transform.Field
>
> @Field
> int x = 0
>
> a {
> assert x == 0
> println x
> x = 1
> assert x == 1
> println x
> }
>
> assert x == 0
> println x
>
> def a(Closure c) {
> c()
> }
>
>
> 
> View this message in context: Closure does not see field when setting value
> Sent from the Groovy Users mailing list archive at Nabble.com.

Closure does not see field when setting value

[Krzysztof Kowalczyk]

Hi,
Today I was quite confused by behaviour of fields inside of closures.When I
read a field value it is visible, but when I try to set it, it is not set,
but a binding is set and then available for rest of the closure. This is
rather confusing, can I disable such behaviour in any way?
import groovy.transform.Field@Fieldint x = 0a {assert x == 0println
xx = 1assert x == 1println x}assert x == 0println xdef a(Closure
c) {c()}  ​




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Closure-does-not-see-field-when-setting-value-tp5736534.html
Sent from the Groovy Users mailing list archive at Nabble.com.