A couple of people have brought up interfaces and classes for containers ala Java's container hierarchy. I was thinking of having 4 interfaces Collection, ISimpleList, IList and IAssocArray. Collection is the root interface and is roughly going to be like Java's Collection. The IList will have several class implementations backed by doubly-linked lists (circular and non-circular) and array lists (which will have a ctor that takes a dynamic array). The ISimpleList will have fewer members and covers singly-linked lists and heaps. The IAssocArray will have three implementations backed by a builtin AA, a sorted AA and a linked AA.  I was thinking of naming the classes things like OList, OArrayList, OCList, OLinkedAA, OAssocArray, OSortedAA, etc. The idea behind the "O" prefix is that the struct forms in MinTL use the "raw" name like List, ArrayList, SortedAA, etc and so some other name is needed to indicate the object form. Using "I" as a prefix for interfaces is pretty common so that seems ok. But the "O" seems odd. Any suggestions for either the naming scheme or the classes in general?

-Ben

I'd prefer C over O... (C for Class), since it looks nicer.

Also, I hope that your ConcurrentAA would also implement the interface.

It's got my vote!  Let me know if you want any help.  I'd like to start using interfaces like this immediately.

John Demme

On Wed, 2005-04-27 at 22:08 -0400, Ben Hinkle wrote:
> A couple of people have brought up interfaces and classes for containers ala Java's container hierarchy. I was thinking of having 4 interfaces Collection, ISimpleList, IList and IAssocArray. Collection is the root interface and is roughly going to be like Java's Collection. The IList will have several class implementations backed by doubly-linked lists (circular and non-circular) and array lists (which will have a ctor that takes a dynamic array). The ISimpleList will have fewer members and covers singly-linked lists and heaps. The IAssocArray will have three implementations backed by a builtin AA, a sorted AA and a linked AA.  I was thinking of naming the classes things like OList, OArrayList, OCList, OLinkedAA, OAssocArray, OSortedAA, etc. The idea behind the "O" prefix is that the struct forms in MinTL use the "raw" name like List, ArrayList, SortedAA, etc and so some other name is needed to indicate the object form. Using "I" as a prefix for interfaces is pretty common so that seems ok. But the "O" seems odd. Any suggestions for either the naming scheme or the classes in general?
> 
> -Ben
> 
> 

The downside of C for Class is that I'm using CList to mean "circular list".
At the time I made that name I actually kept confusing it with C for Class
so I think the thing to do is just rename the circular list to something
like oh.. CircularList. I remember I almost called it Ring but I would
prefer to keep the word List in the name. For anyone using the current CList
... sorry! (good thing D is still so young it doesn't hurt to shift stuff
around). So I like the idea of using C for Class.
The Concurrent classes might be harder to plug into the same interfaces as
the non-concurrent containers since concurrency tends to impose extra
restrictions on behavior. I'll check it out, though. It shouldn't be too
hard to get it to fit.

"John Demme" <me@teqdruid.com> wrote in message news:1114656516.1363.7.camel@localhost.localdomain...
> I'd prefer C over O... (C for Class), since it looks nicer.
>
> Also, I hope that your ConcurrentAA would also implement the interface.
>
> It's got my vote!  Let me know if you want any help.  I'd like to start using interfaces like this immediately.
>
> John Demme
>
> On Wed, 2005-04-27 at 22:08 -0400, Ben Hinkle wrote:
>> A couple of people have brought up interfaces and classes for containers
>> ala
>> Java's container hierarchy. I was thinking of having 4 interfaces
>> Collection, ISimpleList, IList and IAssocArray. Collection is the root
>> interface and is roughly going to be like Java's Collection. The IList
>> will
>> have several class implementations backed by doubly-linked lists
>> (circular
>> and non-circular) and array lists (which will have a ctor that takes a
>> dynamic array). The ISimpleList will have fewer members and covers
>> singly-linked lists and heaps. The IAssocArray will have three
>> implementations backed by a builtin AA, a sorted AA and a linked AA.  I
>> was
>> thinking of naming the classes things like OList, OArrayList, OCList,
>> OLinkedAA, OAssocArray, OSortedAA, etc. The idea behind the "O" prefix is
>> that the struct forms in MinTL use the "raw" name like List, ArrayList,
>> SortedAA, etc and so some other name is needed to indicate the object
>> form.
>> Using "I" as a prefix for interfaces is pretty common so that seems ok.
>> But
>> the "O" seems odd. Any suggestions for either the naming scheme or the
>> classes in general?
>>
>> -Ben
>>
>>
> 

"John Demme" <me@teqdruid.com> wrote in message news:1114656516.1363.7.camel@localhost.localdomain...
> I'd prefer C over O... (C for Class), since it looks nicer.
>
> Also, I hope that your ConcurrentAA would also implement the interface.
>
> It's got my vote!  Let me know if you want any help.  I'd like to start using interfaces like this immediately.

progress update: I've been experimenting with different interfaces and here
are my current favorites:
/**  Interface Hierarchy
 *
 *  Collection
 *    Sliceable
 *      IList
 */

/**  Class Hierarchy
 *
 *  AbstractCollection : Collection
 *    CArrayHeap
 *    AbstractSliceable : Sliceable
 *      CSortedAA
 *      CLinkedAA
 *      AbstractList : IList
 *        CList
 *        CArrayList
 *        CDeque
 *        CCircularList
 *        CSList
 *        CCircularSList
 *  ConcurrentAA : Collection
 *  CBuiltinAA
 */

where
interface Collection(Key,Value) : SeqWithKeys!(Key,Value) {
  bool isEmpty();
  void clear();
  Collection dup();
  size_t length();
  Value* lookup(Key key);
  Value opIndex(Key key);
  void opIndexAssign(Value val, Key key);
  Value remove(Key key);
}

interface Sliceable(Key,Value) : Collection!(Key,Value) {
  Sliceable opSlice(Key a, Key b);
  Sliceable opSlice(Sliceable a, Sliceable b);
  void move(int n = 1, int end = 0);
  int opApply(int delegate(inout Sliceable itr) dg);
  void remove(Sliceable x);
}

interface IList(Value) : Sliceable!(size_t,Value) {
  IList reverse();
  void add(...);
  // opCat operators, too
  Value[] toArray();
  void addTail(Value v);
  void addTail(IList v);
  Value removeTail();
  Value removeHead();
  void addHead(Value v);
  void addHead(IList v);
  void addBefore(IList subv, IList v);
  void addAfter(IList subv, IList v);
  void trim();
}

Recall SeqWithKeys is an interface for opApply over Values and Key/Value pairs. The only concurrent container subclassing Collection is ConcurrentAA since the others don't have close the right functions to implement the interface. Maybe they eventually will. Also note the aliases for Stack, Queue in the struct containers etc will probably map over to aliases like IStack and CStack and CArrayStack etc. I'll probably finish this stuff up over the next few days.

-Ben

/**  Interface Hierarchy
>  *
>  *  Collection
>  *    Sliceable
>  *      IList
>  */

I would appreciate if Interfaces for AAs and Sets were added.
Interestingly enough, my current project doesn't use a single List
anywhere, but uses sets and AAs a lot.  Something like:
Collection
  Sliceable
    IList
    IAA (or IMap, ITable, ect, since IAA doesn't look too nice)
    ISet

I don't know too much about MinTL, but I don't see why ConcurrentAA couldn't implement IAA (and also Slicable).

John Demme

On Sat, 2005-04-30 at 16:18 -0400, Ben Hinkle wrote:
> "John Demme" <me@teqdruid.com> wrote in message news:1114656516.1363.7.camel@localhost.localdomain...
> > I'd prefer C over O... (C for Class), since it looks nicer.
> >
> > Also, I hope that your ConcurrentAA would also implement the interface.
> >
> > It's got my vote!  Let me know if you want any help.  I'd like to start using interfaces like this immediately.
> 
> progress update: I've been experimenting with different interfaces and here
> are my current favorites:
> /**  Interface Hierarchy
>  *
>  *  Collection
>  *    Sliceable
>  *      IList
>  */
> 
> /**  Class Hierarchy
>  *
>  *  AbstractCollection : Collection
>  *    CArrayHeap
>  *    AbstractSliceable : Sliceable
>  *      CSortedAA
>  *      CLinkedAA
>  *      AbstractList : IList
>  *        CList
>  *        CArrayList
>  *        CDeque
>  *        CCircularList
>  *        CSList
>  *        CCircularSList
>  *  ConcurrentAA : Collection
>  *  CBuiltinAA
>  */
> 
> where
> interface Collection(Key,Value) : SeqWithKeys!(Key,Value) {
>   bool isEmpty();
>   void clear();
>   Collection dup();
>   size_t length();
>   Value* lookup(Key key);
>   Value opIndex(Key key);
>   void opIndexAssign(Value val, Key key);
>   Value remove(Key key);
> }
> 
> interface Sliceable(Key,Value) : Collection!(Key,Value) {
>   Sliceable opSlice(Key a, Key b);
>   Sliceable opSlice(Sliceable a, Sliceable b);
>   void move(int n = 1, int end = 0);
>   int opApply(int delegate(inout Sliceable itr) dg);
>   void remove(Sliceable x);
> }
> 
> interface IList(Value) : Sliceable!(size_t,Value) {
>   IList reverse();
>   void add(...);
>   // opCat operators, too
>   Value[] toArray();
>   void addTail(Value v);
>   void addTail(IList v);
>   Value removeTail();
>   Value removeHead();
>   void addHead(Value v);
>   void addHead(IList v);
>   void addBefore(IList subv, IList v);
>   void addAfter(IList subv, IList v);
>   void trim();
> }
> 
> Recall SeqWithKeys is an interface for opApply over Values and Key/Value pairs. The only concurrent container subclassing Collection is ConcurrentAA since the others don't have close the right functions to implement the interface. Maybe they eventually will. Also note the aliases for Stack, Queue in the struct containers etc will probably map over to aliases like IStack and CStack and CArrayStack etc. I'll probably finish this stuff up over the next few days.
> 
> -Ben
> 
> 

I posted without reading the code... stupid me.  This looks like it would work, although the naming makes it a little confusing (at least some me.)  I guess I never thought of a List as being a special case of a table.

John Demme

On Sat, 2005-04-30 at 16:47 -0400, John Demme wrote:
> /**  Interface Hierarchy
> >  *
> >  *  Collection
> >  *    Sliceable
> >  *      IList
> >  */
> 
> I would appreciate if Interfaces for AAs and Sets were added.
> Interestingly enough, my current project doesn't use a single List
> anywhere, but uses sets and AAs a lot.  Something like:
> Collection
>   Sliceable
>     IList
>     IAA (or IMap, ITable, ect, since IAA doesn't look too nice)
>     ISet
> 
> I don't know too much about MinTL, but I don't see why ConcurrentAA couldn't implement IAA (and also Slicable).
> 
> John Demme
> 
> On Sat, 2005-04-30 at 16:18 -0400, Ben Hinkle wrote:
> > "John Demme" <me@teqdruid.com> wrote in message news:1114656516.1363.7.camel@localhost.localdomain...
> > > I'd prefer C over O... (C for Class), since it looks nicer.
> > >
> > > Also, I hope that your ConcurrentAA would also implement the interface.
> > >
> > > It's got my vote!  Let me know if you want any help.  I'd like to start using interfaces like this immediately.
> > 
> > progress update: I've been experimenting with different interfaces and here
> > are my current favorites:
> > /**  Interface Hierarchy
> >  *
> >  *  Collection
> >  *    Sliceable
> >  *      IList
> >  */
> > 
> > /**  Class Hierarchy
> >  *
> >  *  AbstractCollection : Collection
> >  *    CArrayHeap
> >  *    AbstractSliceable : Sliceable
> >  *      CSortedAA
> >  *      CLinkedAA
> >  *      AbstractList : IList
> >  *        CList
> >  *        CArrayList
> >  *        CDeque
> >  *        CCircularList
> >  *        CSList
> >  *        CCircularSList
> >  *  ConcurrentAA : Collection
> >  *  CBuiltinAA
> >  */
> > 
> > where
> > interface Collection(Key,Value) : SeqWithKeys!(Key,Value) {
> >   bool isEmpty();
> >   void clear();
> >   Collection dup();
> >   size_t length();
> >   Value* lookup(Key key);
> >   Value opIndex(Key key);
> >   void opIndexAssign(Value val, Key key);
> >   Value remove(Key key);
> > }
> > 
> > interface Sliceable(Key,Value) : Collection!(Key,Value) {
> >   Sliceable opSlice(Key a, Key b);
> >   Sliceable opSlice(Sliceable a, Sliceable b);
> >   void move(int n = 1, int end = 0);
> >   int opApply(int delegate(inout Sliceable itr) dg);
> >   void remove(Sliceable x);
> > }
> > 
> > interface IList(Value) : Sliceable!(size_t,Value) {
> >   IList reverse();
> >   void add(...);
> >   // opCat operators, too
> >   Value[] toArray();
> >   void addTail(Value v);
> >   void addTail(IList v);
> >   Value removeTail();
> >   Value removeHead();
> >   void addHead(Value v);
> >   void addHead(IList v);
> >   void addBefore(IList subv, IList v);
> >   void addAfter(IList subv, IList v);
> >   void trim();
> > }
> > 
> > Recall SeqWithKeys is an interface for opApply over Values and Key/Value pairs. The only concurrent container subclassing Collection is ConcurrentAA since the others don't have close the right functions to implement the interface. Maybe they eventually will. Also note the aliases for Stack, Queue in the struct containers etc will probably map over to aliases like IStack and CStack and CArrayStack etc. I'll probably finish this stuff up over the next few days.
> > 
> > -Ben
> > 
> > 
> 

I was considering adding an interface for the associative arrays because the
two properties
 Key[] keys;
 Value[] values;
aren't part of the Collection interface (currently). That would be the only
difference between an assoc array interface and a general Collection
interface and so it didn't seem worth it. I'll probably end up putting those
two properties into Collection since it is natural to want to get access to
them.

"John Demme" <me@teqdruid.com> wrote in message news:1114894587.11519.13.camel@localhost.localdomain...
>I posted without reading the code... stupid me.  This looks like it
> would work, although the naming makes it a little confusing (at least some me.)  I guess I never thought of a List as being a special case of a table.
>
> John Demme
>
> On Sat, 2005-04-30 at 16:47 -0400, John Demme wrote:
>> /**  Interface Hierarchy
>> >  *
>> >  *  Collection
>> >  *    Sliceable
>> >  *      IList
>> >  */
>>
>> I would appreciate if Interfaces for AAs and Sets were added.
>> Interestingly enough, my current project doesn't use a single List
>> anywhere, but uses sets and AAs a lot.  Something like:
>> Collection
>>   Sliceable
>>     IList
>>     IAA (or IMap, ITable, ect, since IAA doesn't look too nice)
>>     ISet
>>
>> I don't know too much about MinTL, but I don't see why ConcurrentAA couldn't implement IAA (and also Slicable).
>>
>> John Demme
>>
>> On Sat, 2005-04-30 at 16:18 -0400, Ben Hinkle wrote:
>> > "John Demme" <me@teqdruid.com> wrote in message news:1114656516.1363.7.camel@localhost.localdomain...
>> > > I'd prefer C over O... (C for Class), since it looks nicer.
>> > >
>> > > Also, I hope that your ConcurrentAA would also implement the interface.
>> > >
>> > > It's got my vote!  Let me know if you want any help.  I'd like to
>> > > start
>> > > using interfaces like this immediately.
>> >
>> > progress update: I've been experimenting with different interfaces and
>> > here
>> > are my current favorites:
>> > /**  Interface Hierarchy
>> >  *
>> >  *  Collection
>> >  *    Sliceable
>> >  *      IList
>> >  */
>> >
>> > /**  Class Hierarchy
>> >  *
>> >  *  AbstractCollection : Collection
>> >  *    CArrayHeap
>> >  *    AbstractSliceable : Sliceable
>> >  *      CSortedAA
>> >  *      CLinkedAA
>> >  *      AbstractList : IList
>> >  *        CList
>> >  *        CArrayList
>> >  *        CDeque
>> >  *        CCircularList
>> >  *        CSList
>> >  *        CCircularSList
>> >  *  ConcurrentAA : Collection
>> >  *  CBuiltinAA
>> >  */
>> >
>> > where
>> > interface Collection(Key,Value) : SeqWithKeys!(Key,Value) {
>> >   bool isEmpty();
>> >   void clear();
>> >   Collection dup();
>> >   size_t length();
>> >   Value* lookup(Key key);
>> >   Value opIndex(Key key);
>> >   void opIndexAssign(Value val, Key key);
>> >   Value remove(Key key);
>> > }
>> >
>> > interface Sliceable(Key,Value) : Collection!(Key,Value) {
>> >   Sliceable opSlice(Key a, Key b);
>> >   Sliceable opSlice(Sliceable a, Sliceable b);
>> >   void move(int n = 1, int end = 0);
>> >   int opApply(int delegate(inout Sliceable itr) dg);
>> >   void remove(Sliceable x);
>> > }
>> >
>> > interface IList(Value) : Sliceable!(size_t,Value) {
>> >   IList reverse();
>> >   void add(...);
>> >   // opCat operators, too
>> >   Value[] toArray();
>> >   void addTail(Value v);
>> >   void addTail(IList v);
>> >   Value removeTail();
>> >   Value removeHead();
>> >   void addHead(Value v);
>> >   void addHead(IList v);
>> >   void addBefore(IList subv, IList v);
>> >   void addAfter(IList subv, IList v);
>> >   void trim();
>> > }
>> >
>> > Recall SeqWithKeys is an interface for opApply over Values and
>> > Key/Value
>> > pairs. The only concurrent container subclassing Collection is
>> > ConcurrentAA
>> > since the others don't have close the right functions to implement the
>> > interface. Maybe they eventually will. Also note the aliases for Stack,
>> > Queue in the struct containers etc will probably map over to aliases
>> > like
>> > IStack and CStack and CArrayStack etc. I'll probably finish this stuff
>> > up
>> > over the next few days.
>> >
>> > -Ben
>> >
>> >
>>
> 

"John Demme" <me@teqdruid.com> wrote in message news:1114894587.11519.13.camel@localhost.localdomain...
>I posted without reading the code... stupid me.  This looks like it
> would work, although the naming makes it a little confusing (at least some me.)  I guess I never thought of a List as being a special case of a table.
>
> John Demme

Now that I think about it I'll change the Key parameter for Collection (and probably other things, too) to Index so that it doesn't imply a Collection must be a table indexed by "keys". That will hopefully reduce the confusion. On a side note I'm also thinking of simplifying the sequence stuff to just have one Sequence type instead of one for Value sequences and one for Index/Value pairs.

-Ben

Isn't using I and C or O as prefixes for interfaces and clases hungarian
notaion?
IIRC, the D Style asks us to Just Say No to hungarian notation.



Ben Hinkle wrote:

> The downside of C for Class is that I'm using CList to mean "circular
> list". At the time I made that name I actually kept confusing it with C
> for Class so I think the thing to do is just rename the circular list to
> something like oh.. CircularList. I remember I almost called it Ring but I
> would prefer to keep the word List in the name. For anyone using the
> current CList ... sorry! (good thing D is still so young it doesn't hurt
> to shift stuff around). So I like the idea of using C for Class.
> The Concurrent classes might be harder to plug into the same interfaces as
> the non-concurrent containers since concurrency tends to impose extra
> restrictions on behavior. I'll check it out, though. It shouldn't be too
> hard to get it to fit.
> 
> "John Demme" <me@teqdruid.com> wrote in message news:1114656516.1363.7.camel@localhost.localdomain...
>> I'd prefer C over O... (C for Class), since it looks nicer.
>>
>> Also, I hope that your ConcurrentAA would also implement the interface.
>>
>> It's got my vote!  Let me know if you want any help.  I'd like to start using interfaces like this immediately.
>>
>> John Demme
>>
>> On Wed, 2005-04-27 at 22:08 -0400, Ben Hinkle wrote:
>>> A couple of people have brought up interfaces and classes for containers
>>> ala
>>> Java's container hierarchy. I was thinking of having 4 interfaces
>>> Collection, ISimpleList, IList and IAssocArray. Collection is the root
>>> interface and is roughly going to be like Java's Collection. The IList
>>> will
>>> have several class implementations backed by doubly-linked lists
>>> (circular
>>> and non-circular) and array lists (which will have a ctor that takes a
>>> dynamic array). The ISimpleList will have fewer members and covers
>>> singly-linked lists and heaps. The IAssocArray will have three
>>> implementations backed by a builtin AA, a sorted AA and a linked AA.  I
>>> was
>>> thinking of naming the classes things like OList, OArrayList, OCList,
>>> OLinkedAA, OAssocArray, OSortedAA, etc. The idea behind the "O" prefix
>>> is that the struct forms in MinTL use the "raw" name like List,
>>> ArrayList, SortedAA, etc and so some other name is needed to indicate
>>> the object form.
>>> Using "I" as a prefix for interfaces is pretty common so that seems ok.
>>> But
>>> the "O" seems odd. Any suggestions for either the naming scheme or the
>>> classes in general?
>>>
>>> -Ben
>>>
>>>
>>

"Vegeta" <lord.vegeta@ica.luz.ve> wrote in message news:d6qlak$2ct8$1@digitaldaemon.com...
> Isn't using I and C or O as prefixes for interfaces and clases hungarian
> notaion?
> IIRC, the D Style asks us to Just Say No to hungarian notation.

True - but the names List, Stack etc are already taken for the struct types. Writing out "ListClass" or something seems too wordy. I suppose I could use the same names and rely on the package to distinguish. For example the struct list is mintl.list.List and the class could be mintl.cls.list.List. Right now I have mintl.cls.clist.CList. Using a struct and class List in the same module will presumably be rare so having two Lists might not be that bad.