|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
digitalmars.D.dtl - MinTL interfaces/classes for containers
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → Dejan Lekic <leka entropy.tmok.com> writes:
What about TList ?
"T" because of Type ...
--
...........
Dejan Lekic
http://dejan.lekic.org
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → 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
|
|
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next