[e-lang] Security Implications of Multimethods?

[Sandro Magi]

Continuing a fairly old thread...

Sandro Magi wrote:
> This particular example depends on global multimethods (where resolution
> is global at link time rather than confined to a specific package -- I
> believe Nice supports this), but I think even scoped-multimethods (where
> resolution is confined to a particular package) can be vulnerable to
> this given a particular configuration.

Since the implicit linking of dynamically loaded generic
functions/multimethods is really the source of the problem, reifying the
dispatch tree for each generic function as a capability, could
theoretically "solve" this problem; thus, the new "most-specific"
generic function can only override the existing one if granted explicit
permission to do so.

Further, if each "agent" could have its own dispatch tree comprised of
the generic function implementations that it trusts, then I think all
security concerns are addressable. What constitutes an "agent" is
another question; "thread" is a possible answer.

Predicate dispatching is gaining support and this seems like an area
that needs to be addressed before it's too late to influence the
designs. :-)

As for accessing private members, the most straightforward answer is
that private state is hidden, and accessible only to any
lexically-scoped generic functions that forms the class definition; by
necessity, there can be only one such "most specific" function as all
other attempted definitions would fail with "ambiguous method" errors.

Thus, the public interface provides accessors for anything of interest.
I wonder to what degree this decreases the "openly extensible behaviour"
inherent to predicate dispatching.

Sandro