История изменений
Исправление monk, (текущая версия) :
chunked-input-stream методы chunked-stream-input-chunking-p, chunked-stream-input-index, chunked-stream-input-limit
Вот Вам и контрпример прямо в Вашей цитате: методы не начинаются на chunked-input-stream. Префикс к обобщённым функциям бывает, если он определяет протокол, к которому относятся функции. Но не класс.
P.S. Нашёл, кто придерживается Вашей точки зрения.
Accessor names generally follow a convention of <protocol-name>-<slot-name>, where a «protocol» in this case loosely indicates a set of functions with well-defined behavior.
...
By default, an abstract base class name is used as the notional protocol name, so accessor names default to <class-name>-<slot-name>; while such names are thus quite prevalent, this form is neither required nor even preferred. In general, it contributes to «symbol bloat», and in many cases has led to a proliferation of «trampoline» methods.
...
You must not use generic functions where there is no notional protocol. To put it more concretely, if you have more than one generic function that specializes its Nth argument, the specializing classes should all be descendants of a single class. Generic functions must not be used for «overloading», i.e. simply to use the same name for two entirely unrelated types.
More precisely, it's not really whether they descend from a common superclass, but whether they obey the same «protocol». That is, the two classes should handle the same set of generic functions, as if there were an explicit DEFGENERIC for each method.
(с) https://google.github.io/styleguide/lispguide.xml?showone=CLOS#CLOS
Исходная версия monk, :
chunked-input-stream методы chunked-stream-input-chunking-p, chunked-stream-input-index, chunked-stream-input-limit
Вот Вам и контрпример прямо в Вашей цитате: методы не начинаются на chunked-input-stream. Префикс к обобщённым функциям бывает, если он определяет протокол, к которому относятся функции. Но не класс.
P.S. Нашёл, кто придерживается Вашей точки зрения.
Accessor names generally follow a convention of <protocol-name>-<slot-name>, where a "protocol" in this case loosely indicates a set of functions with well-defined behavior.
...
By default, an abstract base class name is used as the notional protocol name, so accessor names default to <class-name>-<slot-name>; while such names are thus quite prevalent, this form is neither required nor even preferred. In general, it contributes to "symbol bloat", and in many cases has led to a proliferation of "trampoline" methods.
...
You must not use generic functions where there is no notional protocol. To put it more concretely, if you have more than one generic function that specializes its Nth argument, the specializing classes should all be descendants of a single class. Generic functions must not be used for "overloading", i.e. simply to use the same name for two entirely unrelated types.
More precisely, it's not really whether they descend from a common superclass, but whether they obey the same "protocol". That is, the two classes should handle the same set of generic functions, as if there were an explicit DEFGENERIC for each method.
(с) https://google.github.io/styleguide/lispguide.xml?showone=CLOS#CLOS