No I think I keep it as it is, then you have the possibility to insert and replace if exist with '[]= and insert but do not replace with insert. /.../
That's a valid point. Don't really know when the second variety would be useful, but still.
and by returning the value belonging to the key you can make a choice if you want to replace the value or not.
The return value should then be UNDEFINED and not 0 if the insert is successful.
(Besides, global functions for setting and getting the `< function is necessary in the new multisets, so these will probably be candidates for lfuns too.)
What is the name and syntax you have planned for them?
I haven't thought about that yet, besides that it should be something with either a "`" or a "_" first (for the lfuns, that is). ADT.set_order and ADT.get_order seems like reasonable names for the global functions, and then the lfuns would be _set_order and _get_order. Would that do?
The ordering function is a less-than operation and not a three-way comparator (i.e. like strcmp(3)). My reasons for that are:
o It's simpler to make a less-than function. o It's actually not that often one can use the extra information given by a three-way comparator to save calls, at least in binary trees. o It can be slightly less work to do a less-than operation. o The issue of equality is not connected to the order; in a three-way comparator it's easier to make the mistake that it should return 0 only when the operands are equal, and not when they are orderwise unrelated (i.e. the order is partial).
With "if the there hasn't been any changes in the collection", I did not mean that the iterator would not work, I mean that the iterator will not traverse the elements in the same order.
Yes, well, you stated a premise that an iterator on both ordered and unordered collections should be able to fulfill. I wanted to point out that additional conditions can be added to an iterator on an ordered collection.
The main goal I had in mind when creating the collection interfaces was that you could write an algorithm that take a collection and then later reuse it with any other collection. By declaring a lot of methods optional this will spoil the abstractness of the whole thing because then you has to know the implementation of the algorithm before you know if your collection will work anyway.
Not the algorithm itself, only the functions it needs. The algorithms are inherently dependent on the properties of the collections they can work with, and those properties are more than this. I believe that the need by an algorithm for certain functions is an accurate way of expressing which properties it needs(*). Since all the functions are adequately abstracted and don't touch on the implementations in improper ways, it's also an abstract way.
In this view, you're saying that you wish to oversimplify the interface just to be able to make a simple rule that an algorithm that work on one collection will work on all (or on one of a few subsets). The backside is that you then also completely rule out both algorithms and types of collections that can be very useful on various subsets of each other.
Note that you can exploit the looks-like philosophy of the Pike type system to accurately check if a certain collection fits a certain algorithm, since it checks identifier by identifier that the class of the actual argument is compatible with the class of the formal argument.
*) In some cases the same property might be expressed through several functions. Then it's of course not appropriate for a collection implementation to arbitrarily define some of them and leaving out others. Such dependencies should also be part of the documented interface, e.g. by making those functions mandatory in an interface class that itself is optional.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-11-12 11:28: Subject: More about ADTs
I think that implies that the [] operation would return the index as the value if it exists. I.e. foo[0] would return 0, making it necessary to use zero_type. No, please regard the elements as indices and all values as 1. That makes [] and []= work with a minimal amount of special cases (only []= needs one), and besides it's compatible with the multiset data type.
Well I might, but just because you ask so politely ;-). Serious, you're right, I've been looking at java, but that is the Pike way.
Good point, but then it should perhaps throw an error instead? The insert isn't successful, afterall. I don't think it's much use being error tolerant in the insert operation since it's typically only used in ADTs that actually allows duplicate indices, otherwise []= works just as well. Perhaps the insert function shouldn't be defined at all in ADTs that don't allow duplicate indices.
No I think I keep it as it is, then you have the possibility to insert and replace if exist with '[]= and insert but do not replace with insert. And I don't see it as an error if a key already exist, and by returning the value belonging to the key you can make a choice if you want to replace the value or not.
(Besides, global functions for setting and getting the `< function is necessary in the new multisets, so these will probably be candidates for lfuns too.)
What is the name and syntax you have planned for them?
Then the iterator can/should "follow" its index to its new position and then continue stepping from there in a well defined way. The only case where the iterator could reasonably loose track is if the element it's "standing on" is removed. (An ADT could solve this either by refusing the remove, by doing a copy-on-write, or by documenting that the iterator more or less loose track in that case. The new multisets take the last route.)
With "if the there hasn't been any changes in the collection", I did not mean that the iterator would not work, I mean that the iterator will not traverse the elements in the same order.
Then a superclass to Collection would be necessary, and even then it probably would not work out well if Collection isn't designed with a few thoughts in that direction. Most of these issues are solved simply by making functions optional. (That's not really a cost, since a runtime check that a function exists before calling it is unavoidable anyway in Pike.)
The main goal I had in mind when creating the collection interfaces was that you could write an algorithm that take a collection and then later reuse it with any other collection. By declaring a lot of methods optional this will spoil the abstractness of the whole thing because then you has to know the implementation of the algorithm before you know if your collection will work anyway.
/ Peta, jo det är jag