Home » Modeling » Epsilon » Problem deleting model element
| | | |
| Re: Problem deleting model element [message #552505 is a reply to message #552480] |
Thu, 12 August 2010 12:08   |
 Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi Louis,
On 12/08/2010 11:58, Louis Rose wrote:
> Hi Andy,
>
> That ConcurrentModificationException is raised because, in Java (and
> hence in EOL), you can't modify a list while iterating over it with a
> foreach. It's daft, and I don't like it either :)
There's a good reason for this: Iterators need to maintain a state
indicating where they are in a specific iteration. Depending on the
semantics of a collection and the semantics of the specific iterator
(which may not necessarily be a simple sequential iteration), it may be
very difficult to reconstruct or adapt this state when the underlying
collection is modified except through the iterator itself. To avoid
unintended problems with this (such as programs assuming they have
actually seen every element in a collection, when really they haven't),
the Java Collection API opts for a fail-fast policy using the
ConcurrentModificationException.
Having said that, I am not sure why this problem needs to be reflected
into EOL, though. I assume, that you are currently translating an EOL
for loop like this:
EOL:
for a in B {
....
}
Java:
for (BElemType a : B) {
...
}
This will cause ConcurrentModificationExceptions if B is modified in the
loop body.
Alternatively, you could translate this to
for (BElemType a : B.clone()) {
...
}
which creates a copy of the original collection to be iterated, and thus
separates iteration and modification, meaning that no
ConcurrentModificationExceptions occur.
What do you think?
Steffen
>
> The workaround is to use a while rather than a foreach loop:
>
> while (not subroutines.isEmpty()) {
> var s = subroutines.first;
> if(s.`temporary` = true){
> delete s;
> }
> }
>
> Cheers,
> Louis.
>
|
|
| | | | | |
| Re: Problem deleting model element [message #592974 is a reply to message #552480] |
Thu, 12 August 2010 12:08 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi Louis,
On 12/08/2010 11:58, Louis Rose wrote:
> Hi Andy,
>
> That ConcurrentModificationException is raised because, in Java (and
> hence in EOL), you can't modify a list while iterating over it with a
> foreach. It's daft, and I don't like it either :)
There's a good reason for this: Iterators need to maintain a state
indicating where they are in a specific iteration. Depending on the
semantics of a collection and the semantics of the specific iterator
(which may not necessarily be a simple sequential iteration), it may be
very difficult to reconstruct or adapt this state when the underlying
collection is modified except through the iterator itself. To avoid
unintended problems with this (such as programs assuming they have
actually seen every element in a collection, when really they haven't),
the Java Collection API opts for a fail-fast policy using the
ConcurrentModificationException.
Having said that, I am not sure why this problem needs to be reflected
into EOL, though. I assume, that you are currently translating an EOL
for loop like this:
EOL:
for a in B {
....
}
Java:
for (BElemType a : B) {
...
}
This will cause ConcurrentModificationExceptions if B is modified in the
loop body.
Alternatively, you could translate this to
for (BElemType a : B.clone()) {
...
}
which creates a copy of the original collection to be iterated, and thus
separates iteration and modification, meaning that no
ConcurrentModificationExceptions occur.
What do you think?
Steffen
>
> The workaround is to use a while rather than a foreach loop:
>
> while (not subroutines.isEmpty()) {
> var s = subroutines.first;
> if(s.`temporary` = true){
> delete s;
> }
> }
>
> Cheers,
> Louis.
>
|
|
| | | | |
Goto Forum:
Current Time: Thu Apr 18 16:15:20 GMT 2024
Powered by FUDForum. Page generated in 0.02138 seconds |
] 
Search
Help
Register
Login
Home
