www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dtl - MinTL interfaces/classes for containers

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
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
Apr 27 2005
parent reply John Demme <me teqdruid.com> writes:
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
Apr 27 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
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
Apr 27 2005
parent reply Vegeta <lord.vegeta ica.luz.ve> writes:
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
May 22 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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.
May 22 2005
parent reply Dejan Lekic <leka entropy.tmok.com> writes:
What about TList ?
"T" because of Type ...

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
May 24 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 What about TList ?
 "T" because of Type ...


Maybe.. But structs are types, too. Plus I sometimes use T for "template" - 
though I don't think there are any TFoos in MinTL yet.
May 24 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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
Apr 30 2005
parent reply John Demme <me teqdruid.com> writes:
/**  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
Apr 30 2005
parent reply John Demme <me teqdruid.com> writes:
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
Apr 30 2005
next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
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
Apr 30 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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
Apr 30 2005