[Glass] Collection for reduced conflicts, allow indexes and #sort: ?

[Dale K. Henrichs]

----- Original Message -----

| From: "Mariano Martinez Peck" <marianopeck at gmail.com>
| To: "Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
| Cc: glass at lists.gemtalksystems.com
| Sent: Thursday, December 5, 2013 5:46:17 PM
| Subject: Re: [Glass] Collection for reduced conflicts, allow indexes
| and #sort: ?

| On Thu, Dec 5, 2013 at 7:36 PM, Dale K. Henrichs <
| dale.henrichs at gemtalksystems.com > wrote:

| | | From: "Mariano Martinez Peck" < marianopeck at gmail.com >
| | 
| 
| | | To: glass at lists.gemtalksystems.com
| | 
| 
| | | Sent: Thursday, December 5, 2013 8:06:08 AM
| | 
| 
| | | Subject: [Glass] Collection for reduced conflicts, allow indexes
| | | and
| | | #sort: ?
| | 
| 

| | | Hi guys. So...at some point in my app, I have a collection in
| | | which
| | | I
| | | store instances of a persistent class. Imagine class Client, so
| | | at
| | | some point I have a persistent collection of clients.
| | 
| 

| | | Now... I want:
| | 
| 

| | | 1) Reduced conflict collections
| | 
| 
| | | 2) Be able to use indexes if I happen to need them later on (as
| | | far
| | | as I read it needs to be an unordered collection)
| | 
| 
| | correct
| 

| | | 3) Be able to sort the collection given a closure
| | 
| 
| | You can use #sorted: (has the advantage of being defined in Grease
| | so
| | it is "common" between GemStone and Pharo) which takes a standard
| | sort block.
| 
| Thanks for the tip. Indeed, using #sorted: is better!

| | If you have an indexed collection, you cannot use an arbitrary
| | block
| | to take advantage of the index ... you have to define a query
| | against the collection ...
| 

| Yes, what a pity :( It would be so cool if normal closures received
| by select: could detect that you have an index there and use it :)
For 3.2 we are providing a new api for the index system to give you more flexibility in forming queries ... basically you create a query string that looks an awful lot like the smalltalk code that you would write for your closure, but instead of compiling into a closure, we compile it into a `formula` that is made up of `predicates` ... we can match `predicates` to specific indexes and arrange to reorder predicates to take advantage of the indexes ... so a query object when `activated` is the moral equivalent of evaluating a select: block with the difference being that we are able to perform the `select:` operation efficiently ... 

| BTW... (I should test it instead of asking)... indexes are not used
| automagically neither for sorting? say I do a normal #sorted: over a
| unordered collection over a field in which I have an index...would
| that help? Or I need to explicitly use #sortAscending:
| #sortDescending: #sortWith: etc in order to take advantage of the
| index?
You need to use #sortAscending: #sortDescending: #sortWith: to take advantage of the index ... that's the way we match up your "query" with the appropriate index 

| | | Just taking into account 1) and 2) it seems the only option is
| | | RcIdentityBag. Problem is that I cannot sort such collection with
| | | a
| | | simple #sort: aBlockClosure. I saw I have #sortWith:,
| | | #sortAsending:
| | | etc, but that's not what I need. I need to receive a block
| | | closure.
| | 
| 

| | | I can send #asSortedCollection: aClosure to the RcIdentityBag but
| | | that answers an instance of a SortedCollection, not a
| | | RcIdentityBag
| | | sorted, which is different.
| | 
| 

| | Bags, by definition are not ordered, so to get a sorted result you
| | will end up with some sort of SequenceableCollection as a result,
| | by
| | necessity ...
| 

| Indeed, I know it makes sense :)
| I wonder why there isn't any ordered collection that supports RC and
| indexes. Technically, I can understand the latter (I think) but not
| that much the former.

| Thanks Dale and Richard for your answers,

| --
| Mariano
| http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131206/59b5f3cd/attachment.html>