|
| Re: Sorted ELists [message #638264 is a reply to message #638263] |
Wed, 10 November 2010 13:32   |
 Thomas Schindl
Messages: 6651
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 |
J.-P. Pellet
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 |
Ed Merks
Messages: 33140
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03637 seconds
] 
Search
Help
Register
Login
Home
