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
next sibling 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
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
prev sibling next sibling parent 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
prev sibling parent 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