Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Sorted ELists
Sorted ELists [message #638263] Wed, 10 November 2010 12:58 Go to next message
J.-P. Pellet is currently offline J.-P. PelletFriend
Messages: 71
Registered: July 2009
Member
Hi,

What's the best way to automatically keep a list of objects sorted using
a certain comparator, in a multiplicity-many feature? It looks like
subclassing all variants of the existing EList concrete implementations
is a bad idea. I tried adding an adapter responding to the ADD and
ADD_MANY notifications, and sorting the list if necessary, but this
seems to confuse other adapters, which get MOVE notifications before
seeing the original ADD. Is there a mechanism that allows me to delay
the MOVE notifications until later, for example? Or any other preferred
technique?

Thanks,
J.-P.
Re: Sorted ELists [message #638264 is a reply to message #638263] Wed, 10 November 2010 13:32 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6512
Registered: July 2009
Senior Member
Hi,

I don't think using Comparator in List is making a whole lot of sense a
List is SORTED by defintion using the index.

So if your list has to be sorted I think you should provide a
helper-method which takes care of inserting an element at the
appropriate position.

Beside that is it really that your List has be sorted internally or is
it just something the UI needs so the sort should happen outside EMF.

Tom

Am 10.11.10 13:58, schrieb J.-P. Pellet:
> Hi,
>
> What's the best way to automatically keep a list of objects sorted using
> a certain comparator, in a multiplicity-many feature? It looks like
> subclassing all variants of the existing EList concrete implementations
> is a bad idea. I tried adding an adapter responding to the ADD and
> ADD_MANY notifications, and sorting the list if necessary, but this
> seems to confuse other adapters, which get MOVE notifications before
> seeing the original ADD. Is there a mechanism that allows me to delay
> the MOVE notifications until later, for example? Or any other preferred
> technique?
>
> Thanks,
> J.-P.
Re: Sorted ELists [message #638265 is a reply to message #638264] Wed, 10 November 2010 14:33 Go to previous messageGo to next message
J.-P. Pellet is currently offline J.-P. PelletFriend
Messages: 71
Registered: July 2009
Member
Hi Tom,

Thanks for your message!

> I don't think using Comparator in List is making a whole lot of sense a
> List is SORTED by defintion using the index.

The list is ordered, yes, but sorted? It's "sorted" according to the
order in which I've appended elements... which is not appropriate in my
case (see below).

> Beside that is it really that your List has be sorted internally or is
> it just something the UI needs so the sort should happen outside EMF.

It's a list of transactions, each of which has a time stamp. I would
like the model to keep all transactions sorted chronologically at all times.

> So if your list has to be sorted I think you should provide a
> helper-method which takes care of inserting an element at the
> appropriate position.

so, instead of saying,

account.getTransactions().add(transaction); (1)

I should implement addTransaction and then call

account.addTransaction(transaction); (2)

Is this what you mean? This is indeed my fall-back plan, but as calling
(1) is still possible even if I've implemented (2), it's a fragile
situation...

My transactions feature is already marked as "suppressedGetVisibility"
for the outside world. It would be good if somehow it could be generated
with a private getter in the implementation class, too. This would
effectively prevent (1) (though a reflective access to the underlying
list would still be possible for the serializer and the copier). Is it
possible to mark it private, somehow? Or is there any other easier
workaround?

Best,
J.-P.
Re: Sorted ELists [message #638272 is a reply to message #638265] Wed, 10 November 2010 15:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30653
Registered: July 2009
Senior Member
J.-P.

Comments below.

J.-P. Pellet wrote:
> Hi Tom,
>
> Thanks for your message!
>
>> I don't think using Comparator in List is making a whole lot of sense a
>> List is SORTED by defintion using the index.
>
> The list is ordered, yes, but sorted? It's "sorted" according to the
> order in which I've appended elements... which is not appropriate in
> my case (see below).
>
> > Beside that is it really that your List has be sorted internally or is
> > it just something the UI needs so the sort should happen outside EMF.
>
> It's a list of transactions, each of which has a time stamp. I would
> like the model to keep all transactions sorted chronologically at all
> times.
>
>> So if your list has to be sorted I think you should provide a
>> helper-method which takes care of inserting an element at the
>> appropriate position.
>
> so, instead of saying,
>
> account.getTransactions().add(transaction); (1)
>
> I should implement addTransaction and then call
>
> account.addTransaction(transaction); (2)
>
> Is this what you mean? This is indeed my fall-back plan, but as
> calling (1) is still possible even if I've implemented (2), it's a
> fragile situation...
No matter what, a List does not enforce order. So it will need to be
that way by convention. You might just won't to provide an operation
that returns a sorted list...
>
> My transactions feature is already marked as "suppressedGetVisibility"
> for the outside world. It would be good if somehow it could be
> generated with a private getter in the implementation class, too.
Think about what will happen when deserializing or when using
EcoreUtil.copy. The object will likely be added before the feature that
determines its order is set. No good will come of that right?
> This would effectively prevent (1) (though a reflective access to the
> underlying list would still be possible for the serializer and the
> copier). Is it possible to mark it private, somehow? Or is there any
> other easier workaround?
At best you should consider adding a constraint that tests whether the
list is sorted so that you can mark it as an error when it's not. It's
impossible to guarantee that the order will always be in effect; after
all, the value of the feature that determines the order can change, right?
>
> Best,
> J.-P.
Re: Sorted ELists [message #638438 is a reply to message #638272] Thu, 11 November 2010 09:44 Go to previous message
J.-P. Pellet is currently offline J.-P. PelletFriend
Messages: 71
Registered: July 2009
Member
>> My transactions feature is already marked as "suppressedGetVisibility"
>> for the outside world. It would be good if somehow it could be
>> generated with a private getter in the implementation class, too.
> Think about what will happen when deserializing or when using
> EcoreUtil.copy. The object will likely be added before the feature that
> determines its order is set. No good will come of that right?

Yes, you're right.

>> This would effectively prevent (1) (though a reflective access to the
>> underlying list would still be possible for the serializer and the
>> copier). Is it possible to mark it private, somehow? Or is there any
>> other easier workaround?
> At best you should consider adding a constraint that tests whether the
> list is sorted so that you can mark it as an error when it's not. It's
> impossible to guarantee that the order will always be in effect; after
> all, the value of the feature that determines the order can change, right?

Yes, they could, indeed. Maybe a sorted view is the simplest solution, then.

Thanks for your help!

J.-P.
Previous Topic:Explicitly storing default values in XML resources
Next Topic:Root Class of Ecore model package instance
Goto Forum:
  


Current Time: Thu Nov 21 00:31:33 GMT 2019

Powered by FUDForum. Page generated in 0.01917 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top