Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner

[Stefan F. <ste...@we...>]

Erik,
answers see below:

On 09/03/2012 05:01 PM, Erik Vos wrote:
> Stefan,
>
> I do not want to have a big argument over these matters, that's not worth
> it, but I'm trying to understand the reasoning behind your 'natural order',
> and I cannot find it.
>
>> You can call this reverted, but your proposal is symmetric:
>> Take the indexInCompany as the default Comparator and create the Player
>> portfolios with the a Comparator based on the order of president and
>> certificate type.
>>
>> As soon as you want support two (or more) different sortings you need one
>> (or more) "non-natural" Comparator(s).
>
> But what is then the use case of your 'natural order'?

Sorry mentioned it at the beginning of the discussion, but maybe did not 
stress enough, that it is an arbitrary choice.

It is the one used for display in the UI: For certificates it is the 
(default) sorting for the detailed certificate list in the UI.

So the "advantage" of a sorted set (collection) is that you do not have 
to sort again anytime you update the UI.

The wording "natural order" only refers to the fact that I define it as 
the order for the Comparable interface: So any sort without an explicit 
Comparator given will use that order.

>
> Let's look at the most obvious use cases:
>
> 1. Initial purchase from IPO. Fixed order, as configured. This usage calls
> for a List.

I totally agree that the IPO is sorted differently than other Portfolio 
(both for display and usage). But you won't disagree, that the IPO is 
sorted.

>
> 2. Purchase from Pool or Treasury. In most cases, just one share can be
> bought, so all you need is a single (any) share per share size. Any ordering
> can handle this, though a Map per share type (size) would help, or a Set per
> share type. Is that what you do? Current code just iterates over all shares,
> and any iterable collection type can handle this equally well, though a List
> looks most efficient. Order doesn't matter at all.

Certificates are stored in a PortfolioMap, however the keys are 
PublicCompanies and not CertificateTypes.
Main reason is that Portfolio only allows one Portfolio per Type and 
PortfolioMap only allows one level of typing (we would need a Map of Map).
So it would be possible to create a Portfolio that separates by
CertificateTypes, but then we would have to filter by company.

>
> 3. Finding which and how many shares can be sold. Here you need counts of
> each share type (size). Basically what I said for use case 2 applies here
> too.
>
> 4. Add up share worth. Again, any iterable collection can handle this.
>
> Nowhere I can find any reason to have such a thing as your 'natural order'.
> So I'm curious what use case you think would benefit from such an order.  I
> must be missing some point...
> (Of course it's possible that you have explained it in the past perfectly
> well, and then I apologize for having forgotten it).
>

Again: You are right those use cases give no reason for different 
orderings, except for the fact that I believe the ordering of the IPO 
and the ordering to display the shares in the UI can be different.

Could it be that you do not mind the ordering as such, but that you 
still dislike the choice of a set instead of a list?
And you are right that if coded correctly a list works as well as a 
(sorted)set and is more efficient, but I prefer the built-in protection 
of the set against coding errors that create undo problems that are 
difficult to track.

Stefan