You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Felix Dorner <fe...@gmail.com> on 2018/10/16 10:23:10 UTC

Calling 'each' on org.eclipse.emf.common.util.TreeIterator

Hi,

I can do:
def a = [1,2,3].iterator()
a.each {
   println it
}

Cool, I can walk EMF EObject trees like this, I thought:

Iterator i = anEObject.eAllContents() // this gives a TreeIterator, a
subinterface of Iterator
it.each {
  println it
}

But that doesn't work :(. It only prints anEObject, not the whole content
tree. Anyone can explain why?


-- 
Linux. The choice of a GNU generation.

Re: Re: Calling 'each' on org.eclipse.emf.common.util.TreeIterator

Posted by Felix Dorner <fe...@gmail.com>.
Ok, I will see if I can figure out how this works. I already put
breakpoints in the two methods, but the stack looks like Chinese to me when
it hits 😀

Felix

On Wed, Oct 17, 2018, 09:44 Jochen Theodorou <bl...@gmx.org> wrote:

> If it is chosen random it is wrong. It should be either always the same or
> fail. This sounds like a bug
>
> *Gesendet:* Dienstag, 16. Oktober 2018 um 23:36 Uhr
> *Von:* "Felix Dorner" <fe...@gmail.com>
> *An:* users@groovy.apache.org
> *Betreff:* Re: Calling 'each' on org.eclipse.emf.common.util.TreeIterator
> Ok so to summarize, the trap is that I call each {} on an object that is
> both, an List/Iterable and an Iterator at the same time. The result is that
> either of these two is called, and it happens to be random which one.
>
> http://docs.groovy-lang.org/docs/groovy-2.5.1/html/api/org/codehaus/groovy/runtime/DefaultGroovyMethods.html#each-java.util.Iterator-groovy.lang.Closure-
>
> http://docs.groovy-lang.org/docs/groovy-2.5.1/html/api/org/codehaus/groovy/runtime/DefaultGroovyMethods.html#each-java.lang.Iterable-groovy.lang.Closure-
>
>
>
>
> On Tue, Oct 16, 2018 at 6:59 PM Felix Dorner <fe...@gmail.com>
> wrote:
>
>> I think I "know" what's going on.. I have a hard time trying to figure
>> actually out which 'each' implementation is called, but if it is
>> "DefaultGroovyMethods.each", this will not work: The default groovy methods
>> each calls 'iterator' on the argument, which happens to be defined in the
>> iterator that I am testing, because that iterator is also a list... (But
>> the tree iterator contents are actually more than the contents of that
>> list, because the list is a list of root elements, just imagine a dom tree,
>> it's the same thing). I'll figure something out.
>>
>>
>>
>> On Tue, Oct 16, 2018 at 6:17 PM Felix Dorner <fe...@gmail.com>
>> wrote:
>>
>>> If I use hasNext/next in a while loop, I get at the content as expected,
>>> but not if I use the collection extensions such as 'each'. I don't know
>>> where the magic fails, but I want to find out.. The iterator that is being
>>> used is created here:
>>>
>>>
>>> http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/impl/BasicEObjectImpl.java#n832
>>> and that is an anonymous subtype of
>>>
>>> http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/AbstractTreeIterator.java
>>>
>>>
>>>
>>>
>>> On Tue, Oct 16, 2018 at 3:21 PM Paul King <pa...@asert.com.au> wrote:
>>>
>>>> I'd expect that to work the same as if you used a while loop with
>>>> hasNext() and next(). If your data structure has further containers and
>>>> next() doesn't normally walk through the containers, then I'd expect you to
>>>> have more work to do. Is that not what you are seeing?
>>>>
>>>> Cheers, Paul.
>>>>
>>>> On Tue, Oct 16, 2018 at 8:23 PM Felix Dorner <fe...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I can do:
>>>>> def a = [1,2,3].iterator()
>>>>> a.each {
>>>>>    println it
>>>>> }
>>>>>
>>>>> Cool, I can walk EMF EObject trees like this, I thought:
>>>>>
>>>>> Iterator i = anEObject.eAllContents() // this gives a TreeIterator, a
>>>>> subinterface of Iterator
>>>>> it.each {
>>>>>   println it
>>>>> }
>>>>>
>>>>> But that doesn't work :(. It only prints anEObject, not the whole
>>>>> content tree. Anyone can explain why?
>>>>>
>>>>>
>>>>> --
>>>>> Linux. The choice of a GNU generation.
>>>>>
>>>>
>>>
>>> --
>>> Linux. The choice of a GNU generation.
>>>
>>
>>
>> --
>> Linux. The choice of a GNU generation.
>>
>
>
> --
> Linux. The choice of a GNU generation.
>

Re: Calling 'each' on org.eclipse.emf.common.util.TreeIterator

Posted by Felix Dorner <fe...@gmail.com>.
Ok so to summarize, the trap is that I call each {} on an object that is
both, an List/Iterable and an Iterator at the same time. The result is that
either of these two is called, and it happens to be random which one.
http://docs.groovy-lang.org/docs/groovy-2.5.1/html/api/org/codehaus/groovy/runtime/DefaultGroovyMethods.html#each-java.util.Iterator-groovy.lang.Closure-
http://docs.groovy-lang.org/docs/groovy-2.5.1/html/api/org/codehaus/groovy/runtime/DefaultGroovyMethods.html#each-java.lang.Iterable-groovy.lang.Closure-




On Tue, Oct 16, 2018 at 6:59 PM Felix Dorner <fe...@gmail.com> wrote:

> I think I "know" what's going on.. I have a hard time trying to figure
> actually out which 'each' implementation is called, but if it is
> "DefaultGroovyMethods.each", this will not work: The default groovy methods
> each calls 'iterator' on the argument, which happens to be defined in the
> iterator that I am testing, because that iterator is also a list... (But
> the tree iterator contents are actually more than the contents of that
> list, because the list is a list of root elements, just imagine a dom tree,
> it's the same thing). I'll figure something out.
>
>
>
> On Tue, Oct 16, 2018 at 6:17 PM Felix Dorner <fe...@gmail.com>
> wrote:
>
>> If I use hasNext/next in a while loop, I get at the content as expected,
>> but not if I use the collection extensions such as 'each'. I don't know
>> where the magic fails, but I want to find out.. The iterator that is being
>> used is created here:
>>
>>
>> http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/impl/BasicEObjectImpl.java#n832
>> and that is an anonymous subtype of
>>
>> http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/AbstractTreeIterator.java
>>
>>
>>
>>
>> On Tue, Oct 16, 2018 at 3:21 PM Paul King <pa...@asert.com.au> wrote:
>>
>>> I'd expect that to work the same as if you used a while loop with
>>> hasNext() and next(). If your data structure has further containers and
>>> next() doesn't normally walk through the containers, then I'd expect you to
>>> have more work to do. Is that not what you are seeing?
>>>
>>> Cheers, Paul.
>>>
>>> On Tue, Oct 16, 2018 at 8:23 PM Felix Dorner <fe...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I can do:
>>>> def a = [1,2,3].iterator()
>>>> a.each {
>>>>    println it
>>>> }
>>>>
>>>> Cool, I can walk EMF EObject trees like this, I thought:
>>>>
>>>> Iterator i = anEObject.eAllContents() // this gives a TreeIterator, a
>>>> subinterface of Iterator
>>>> it.each {
>>>>   println it
>>>> }
>>>>
>>>> But that doesn't work :(. It only prints anEObject, not the whole
>>>> content tree. Anyone can explain why?
>>>>
>>>>
>>>> --
>>>> Linux. The choice of a GNU generation.
>>>>
>>>
>>
>> --
>> Linux. The choice of a GNU generation.
>>
>
>
> --
> Linux. The choice of a GNU generation.
>


-- 
Linux. The choice of a GNU generation.

Re: Calling 'each' on org.eclipse.emf.common.util.TreeIterator

Posted by Felix Dorner <fe...@gmail.com>.
I think I "know" what's going on.. I have a hard time trying to figure
actually out which 'each' implementation is called, but if it is
"DefaultGroovyMethods.each", this will not work: The default groovy methods
each calls 'iterator' on the argument, which happens to be defined in the
iterator that I am testing, because that iterator is also a list... (But
the tree iterator contents are actually more than the contents of that
list, because the list is a list of root elements, just imagine a dom tree,
it's the same thing). I'll figure something out.



On Tue, Oct 16, 2018 at 6:17 PM Felix Dorner <fe...@gmail.com> wrote:

> If I use hasNext/next in a while loop, I get at the content as expected,
> but not if I use the collection extensions such as 'each'. I don't know
> where the magic fails, but I want to find out.. The iterator that is being
> used is created here:
>
>
> http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/impl/BasicEObjectImpl.java#n832
> and that is an anonymous subtype of
>
> http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/AbstractTreeIterator.java
>
>
>
>
> On Tue, Oct 16, 2018 at 3:21 PM Paul King <pa...@asert.com.au> wrote:
>
>> I'd expect that to work the same as if you used a while loop with
>> hasNext() and next(). If your data structure has further containers and
>> next() doesn't normally walk through the containers, then I'd expect you to
>> have more work to do. Is that not what you are seeing?
>>
>> Cheers, Paul.
>>
>> On Tue, Oct 16, 2018 at 8:23 PM Felix Dorner <fe...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I can do:
>>> def a = [1,2,3].iterator()
>>> a.each {
>>>    println it
>>> }
>>>
>>> Cool, I can walk EMF EObject trees like this, I thought:
>>>
>>> Iterator i = anEObject.eAllContents() // this gives a TreeIterator, a
>>> subinterface of Iterator
>>> it.each {
>>>   println it
>>> }
>>>
>>> But that doesn't work :(. It only prints anEObject, not the whole
>>> content tree. Anyone can explain why?
>>>
>>>
>>> --
>>> Linux. The choice of a GNU generation.
>>>
>>
>
> --
> Linux. The choice of a GNU generation.
>


-- 
Linux. The choice of a GNU generation.

Re: Calling 'each' on org.eclipse.emf.common.util.TreeIterator

Posted by Felix Dorner <fe...@gmail.com>.
If I use hasNext/next in a while loop, I get at the content as expected,
but not if I use the collection extensions such as 'each'. I don't know
where the magic fails, but I want to find out.. The iterator that is being
used is created here:

http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/impl/BasicEObjectImpl.java#n832
and that is an anonymous subtype of
http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/AbstractTreeIterator.java




On Tue, Oct 16, 2018 at 3:21 PM Paul King <pa...@asert.com.au> wrote:

> I'd expect that to work the same as if you used a while loop with
> hasNext() and next(). If your data structure has further containers and
> next() doesn't normally walk through the containers, then I'd expect you to
> have more work to do. Is that not what you are seeing?
>
> Cheers, Paul.
>
> On Tue, Oct 16, 2018 at 8:23 PM Felix Dorner <fe...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I can do:
>> def a = [1,2,3].iterator()
>> a.each {
>>    println it
>> }
>>
>> Cool, I can walk EMF EObject trees like this, I thought:
>>
>> Iterator i = anEObject.eAllContents() // this gives a TreeIterator, a
>> subinterface of Iterator
>> it.each {
>>   println it
>> }
>>
>> But that doesn't work :(. It only prints anEObject, not the whole content
>> tree. Anyone can explain why?
>>
>>
>> --
>> Linux. The choice of a GNU generation.
>>
>

-- 
Linux. The choice of a GNU generation.

Re: Calling 'each' on org.eclipse.emf.common.util.TreeIterator

Posted by Paul King <pa...@asert.com.au>.
I'd expect that to work the same as if you used a while loop with hasNext()
and next(). If your data structure has further containers and next()
doesn't normally walk through the containers, then I'd expect you to have
more work to do. Is that not what you are seeing?

Cheers, Paul.

On Tue, Oct 16, 2018 at 8:23 PM Felix Dorner <fe...@gmail.com> wrote:

> Hi,
>
> I can do:
> def a = [1,2,3].iterator()
> a.each {
>    println it
> }
>
> Cool, I can walk EMF EObject trees like this, I thought:
>
> Iterator i = anEObject.eAllContents() // this gives a TreeIterator, a
> subinterface of Iterator
> it.each {
>   println it
> }
>
> But that doesn't work :(. It only prints anEObject, not the whole content
> tree. Anyone can explain why?
>
>
> --
> Linux. The choice of a GNU generation.
>