On Tue, Sep 16, 2014 at 1:04 AM, Nick Wellnhofer <[email protected]> wrote: > I'm more concerned with the waste of memory. I'd happily sacrifice some more > cycles to find a solution that doesn't need those sparse arrays.
I suppose there's always linear search or binary search. We could speed that up using your proposed itable_cache variable, but moved to the Class object -- which would save adding overhead to every object and help achieve the objective of reducing memory footprint. This approach seems to violate the principle of avoiding non-constant global variables, but it's only a cache and we don't need to update it atomically. The downside would be non-linear performance degradation due to thrashing in unpredictable situations, possibly worsened in multi-threaded operation. However, performance would probably never be that bad, because subtleties of method dispatch are going to have only minor impact on non-trivial Clownfish-based programs. > Even if a class from module A implements an interface of module B, it's > possible that the class already provides the added method or that the new > method has a concrete implementation defined in the interface (like you > suggest below). I think we should support adding concrete methods to later versions of an interface/trait/role, but that we should forbid adding abstract methods. If you really need to add abstract functionality, the workaround is to add a new concrete method which dies at runtime. Marvin Humphrey
