by
Carl Ranson >> Sun, 7 Mar 1999 22:15:30 GMT
<whinge>
I've always found it a bit disapointing that Jade hides away the collection types. You would think jade only uses a small set of methods for its automatic update mechanism, and should be able to work data structures other than bTrees.
</whinge>
What do you mean by "hides away the collection types"? Do you mean that the collection implementations are hidden? Do you have a need to substitute your own collection implementations?
Theo
Ever noticed how Jade prevents you from adding attributes to collection classes.
Nor can you subclass from those classes. If I wanted to add a BAG (a Set with cardinality of members) class subclassed from BTree I would be stuck.
In theory, if collections wern't treated as special classes by Jade, you could make an inverse that used a binary tree or a hash table or whatever.
I'm not necessarily saying that it would be wise or even pracatical to write a replacement class for Jades collections, I apreciate that this would have implications when you come to things like reorgs. But there are some things that Jade must be doing for collections that could have been useful for the general population.
Take the membership mechanism for instance, this is basically a generic class mechanism, but it is only available to Jade itself. There may have been sound reasons for this decision but other OO languages have this feature and many consider it very useful, especially when dealing with data structures.
Carl