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 <blackd...@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" <felix.dor...@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 <felix.dor...@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 <felix.dor...@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 <felix.dor...@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.
>
