Open markuspf opened 6 years ago
Well, we can do that, but then we should also prevent our objects from being made immutable. (Can one do that? @stevelinton ?) Right now, one can do that, with all the bad consequences...:
gap> heap:=BinaryHeap();
<binary heap with 0 entries>
gap> MakeImmutable(heap);;
gap> IsEmpty(heap);
true
gap> Push(heap,1);
gap> IsEmpty(heap);
true
So an immediate thing to do here is to require IsMutable
in the Push
and Pop
declarations resp. methods. But ideally, it just should be impossible to do MakeImmutable
Looking at the code for MakeImmutable
, it calls MakeImmutablePosObj
, which just does this:
CALL_2ARGS( RESET_FILTER_OBJ, obj, IsMutableObjFilt );
CALL_1ARGS( PostMakeImmutableOp, obj);
So we can install a method which gets triggered after the fact... but no way to prevent the operation from happening :-(.
We had this debate many years ago over Iterators. The conclusion is that Immutable structures, while not necessarily very useful, are harmless and forbidding them creates problems elsewhere. So in this case Push and Pop would be declared requiring IsMutable. You could still, for example ask for the Size of Max of such a heap. For something like a binary search tree there is still quite a lot you can do with an immutable tree (and one could use PostMakeImmutable to balance it or turn it into an immutable sorted list or whatever).
What exactly is this about? Is it still relevant?