bug#16980: eieio-generic-call shouldn't load libraries

bug#16980: eieio-generic-call shouldn't load libraries

[Jonas Bernoulli]

eieio-generic-call loads the respective library when the first method
argument is a symbol which also happens to be the name of an autoloaded
function.  This is justifies like this:

    Is the class passed in autoloaded?
    Since class names are also constructors, they can be autoloaded
    via the autoload command.  Check for this, and load them in.
    It is ok if it doesn't turn out to be a class.  Probably want that
    function loaded anyway.

That assumption isn't always true.  E.g. I have written a little tool
that deals with Elisp libraries.  Some of methods are not only
implemented for objects that represent libraries but also for symbols
which stand for such libraries.  I was very surprised when calling these
methods started to load libraries.

  Best regards,
  Jonas

bug#16980: eieio-generic-call shouldn't load libraries

[Jonas Bernoulli]

Jonas Bernoulli <jonas@bernoul.li> writes:

> eieio-generic-call loads the respective library when the first method
> argument is a symbol which also happens to be the name of an autoloaded
> function.

This function does not exist anymore and this behavior does not appear
to have survived all the major refactorings.  I also tried to reproduce
the old behavior, but that too indicates that the issue is gone:

,----
| (cl-defmethod testibus ((arg (eql battery)))
|   arg)
| 
| (list (featurep 'battery)
|       (testibus 'battery)
|       (featurep 'battery)
|       (require  'battery))
| => (nil battery nil battery)
`----

So this can be close.  Thanks.

bug#16980: eieio-generic-call shouldn't load libraries

[Lars Ingebrigtsen]

Jonas Bernoulli <jonas@bernoul.li> writes:

> So this can be close.  Thanks.

OK; closed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no