Collection with memory?

Hi

I need a collection that does the following:

col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection.
col findFirst: [:each | each first = $a]
     > a12
col findFirst: [:each | each first = $a]
     > a13

Do you know a collection that would work?
So I have the impression that such behavoir could be defined with a kind
of methods wrapper.

Stef

may be a first step would be to have findFirst: aBlock startingAt: based
on findFirst:


findFirst: aBlock
     "Return the index of my first element for which aBlock evaluates as
true."

     | index |
     index := 0.
     [(index := index + 1) <= self size] whileTrue:
         [(aBlock value: (self at: index)) ifTrue: [^index]].
     ^ 0

Le 22/03/2015 18:57, stepharo a écrit : May be this "memory" could be implemented in another object (and/or
Traits?) , allowing several threads to traverse the collection, and add
extensibility to the collection framework.

The general idea, inspired from dotnet+smalltalk
(I don't know if this fit well with smalltalk patterns, may be total
junk and not doable ? -btw it's just a proposition)

Collection>> asQueryable
"=> a Queryable Object that would implement first, next, based on a
predicate."
        ^Queryable on: self readStream.

Queryable class >> on: aStream
        ^self new on: aStream

Queryable>> where: aPredicateBlock
        self predicate: aPredicateBlock

Queryable>> first
        self stream reset .
        ^self next.
Queryable>>next
        [self stream atEnd not
        and: [ (self predicate value: (current := self stream next)))] whileFalse.
        ^ self stream atEnd ifTrue: [nil]
                ifFalse: [self current].
(...)

col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asQueryable where: [:each
| each first = $a].
col first. -> 'a12'
col next. -> 'a13'

Those dotnet linq patterns are cool, on a dynamic langage like smalltalk
with
tools like GTInspector + roassal and Moose, wouldn't it be ultra cool ?
  :)

--
Regards,

Alain

> On 22 Mar 2015, at 21:44, Denis Kudriashov <[hidden email]> wrote:
>
> Hi
>
> It is another perfect task for XStreams:
>
> r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a].
> r get > a12
> r get > a13

Beautiful !

Thx Denis.

Le 22/03/2015 21:44, Denis Kudriashov a écrit :
> Hi
>
> It is another perfect task for XStreams:
>
> r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each |
> each first = $a].
> r get > a12
> r get > a13
>
Looks interesting :)
You have a link for this package in Pharo (or squeak) ?
I found only java package, or mails and slides talking of it in smalltalk
TIA

--
Regards,

Alain

This is like the Iterator Design pattern and this is interesting.
Why don't you give a try to see how it grows?
Thanks Alain

Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :
Yes but with
r next.
r next

I was reading the XTreams API recently but this is forbidden for me to
open another project before finishing
what I started. Now if somebody else would like to help pushing Xtreams
in Pharo 50.
:)

https://code.google.com/p/xtreams/



Le 22/3/15 22:27, Alain Rastoul a écrit :

The choice for different selector names was intentional, by design. To avoid confusion, because #next and #get are not 100% identical (semantically). This is an important point.

> I was reading the XTreams API recently but this is forbidden for me to open another project before finishing
> what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50.
> :)

Well, it does/did load OK in Pharo 3 and probably will in 4 too.

https://ci.inria.fr/pharo-contribution/job/Xtreams/

Le 22/03/2015 22:42, stepharo a écrit :
> https://code.google.com/p/xtreams/
Thank you, I just found it too by watching the Martin Kobetic video on
youtube.
Very interesting

--
Regards,

Alain

Le 22/03/2015 22:39, stepharo a écrit :
> This is like the Iterator Design pattern and this is interesting.
Yes, usually in dotnet IQueryable is implemented by (or on top of) a
IEnumerable. It is one of the key elements of Linq that makes Linq very
user friendly for developers
> Why don't you give a try to see how it grows?
I did a small try . it works, and there was not too much errors in my
suggestion . sometimes I surprise myself ... ;-)
I think it could be cool not only for collections, but with Glorp for
example (translate predicates to sql, some kind of "Linq for
smalltalk"). I think I'll dig a bit in that direction
May be time for  some explorations with Glorp.

--
Regards,

Alain

Le 22/3/15 23:01, Sven Van Caekenberghe a écrit : No I asked martin personally. This is the real reason.  There were also
experimenting to offer an API closer to other language.
So that we have
r get.
r next: 4

superb inconsistencet
>
>> I was reading the XTreams API recently but this is forbidden for me to open another project before finishing
>> what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50.
>> :)
> Well, it does/did load OK in Pharo 3 and probably will in 4 too.
>
> https://ci.inria.fr/pharo-contribution/job/Xtreams/
Yes loading is just a part of the story :)
We should remove the old ones.

And we should revise the API because
  I **hate ++, -=,  +=

Le 22/3/15 23:10, Alain Rastoul a écrit : Excellent! Improve our lives :)

IIRC, one difference between #get and #next is that

 get cannot return nil and will throw an Incomplete exception when EOF
 next can return nil and might throws an Exception

Changing the meaning of an existing selector will cause many problems and discussions. People will think they do not have to change anything and they will be wrong.

Yeah, but is not because it looks a bit like C++ that it is no longer Smalltalk, these are still normal messages.

But yes, some API discussions are possible.

The problem is that    
    - we do not want to open alone another subproject
    - we would like to remove the old stream (make them loadable)
    - we should not get the system with two stream libraries.

Stef

2015-03-23 0:40 GMT+03:00 stepharo <[hidden email]>:

Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :

On 22 Mar 2015, at 21:44, Denis Kudriashov <[hidden email]> wrote:

Hi

It is another perfect task for XStreams:

r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a].
r get > a12
r get > a13

Beautiful !

Yes but with
r next.
r next

I was reading the XTreams API recently but this is forbidden for me to open another project before finishing
what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50.

I think it is important to have XStreams in pharo by default. Because current streams (from Smalltalk 80) are too powerfull. And when XStreams not in image or can't be loaded easilly people can prefer to use existed streams solution. I was such man when I was need quickly solve some parsing and analizing data task but I can't load XStreams. And I was solve my task with classic streams. It was simple solution. But with XStreams it will be much compact and intuitive implementation.