What's wrong with CLOS generics? Not only does it have function "overloading", it has it on any of the parameters while still being object oriented.

    (defclass Shape () ())
    (defclass Rectangle (Shape) ())
    (defclass Ellipse (Shape) ())
    (defclass Triangle (Shape) ())

    ; Having a defgeneric is not strictly necessary in CLOS. The code would
    ; work without this definition. However, this is good practice as it gives
    ; us a natural place to document the generic interface methods are expected
    ; to implement. It also lets us add a default handler with a meaningful
    ; error message, if no suitable method was found in some case.
    (defgeneric intersect (x y)
      (:documentation "Shape intersection")
      (:method (x y)
        (error "Cannot interesect these shapes")))

    (defmethod intersect ((r Rectangle) (e Ellipse))
      (format t "Rectangle x Ellipse [names r=~a, e=~a]~&"
              (type-of r) (type-of e)))

    (defmethod intersect ((r1 Rectangle) (r2 Rectangle))
      (format t "Rectangle x Rectangle [names r1=~a, r2=~a]~&"
              (type-of r1) (type-of r2)))

    (defmethod intersect ((r Rectangle) (s Shape))
      (format t "Rectangle x Shape [names r=~a, s=~a]~&"
              (type-of r) (type-of s)))

>maps

make-hash-table

It has both of those features in several forms.