On Mon, Sep 1, 2014 at 2:43 AM, Nick Wellnhofer <[email protected]> wrote:
> The main argument not to implement multiple classes in the same file is to
> have a better separation of concerns.
There's also knowing what header file corresponds to a given public class,
since Clownfish does not at present impose any restriction on where classes
may be defined.
But imports are a larger question that we need to sort out; I'll take that up
in another thread later.
> I don't want to change the way the end of iteration is detected. Next should
> still return false after the iterator is finished. I only propose that once
> Next has returned false, calls to Get_Key and Get_Value shouldn't be
> allowed. This wouldn't affect the standard idiom:
>
> // Works like before.
> HashIterator *iter = HashIter_new(hash);
> while (HashIter_Next(iter)) {
> Obj *key = HashIter_Get_Key(iter);
> Obj *value = HashIter_Get_Value(iter);
> }
> // Calling Get_Key or Get_Value now would throw an exception.
>
> If someone calls Get_Key or Get_Value after the end of iteration, it's most
> likely a programming error, and throwing an exception helps to detect this.
+1
Hash does not allow NULL keys. It is useful to propagate that invariant to
HashIter_Get_Key(), because it eliminates a need for NULL checking in client
code.
A related bug is that we do not enforce that Hash keys must be immutable.
Hash *hash = Hash_new(0);
ByteBuf *foo = BB_new_bytes("foo", 4)
Hash_Store(hash, (Obj*)foo, NULL);
VArray *keys = Hash_Keys(hash);
ByteBuf *key = (ByteBuf*)VA_Fetch(keys, 0);
BB_Set_Size(key, 2); // Uh oh.
There's a straightforward solution, though. 99% of the time, Hash uses only
String keys. String is immutable. We should consider requiring Hash keys to
be Strings. There are a lot of advantages, and few downsides.
Marvin Humphrey
