<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Anton,<br>
<br>
Thank you very much for your mail. It prompted me<br>
to explain what I'm thinking of in a much more<br>
clear (I hope!!) way. Here we go:<br>
<br>
Anton Vodonosov wrote:<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap=""> What is the difference
for modularity in case of subclassing, from other cases were we apply modularity?
I can't find the difference.
</pre>
</blockquote>
Here's the greater idea.<br>
<br>
If you have a module, by using CL packages (without<br>
any change to CL), it is possible to have more than<br>
one set of exports. So, you can offer different<br>
interfaces to different callers. By interfaces<br>
in this context I mean the set of symbols<br>
that are exported.<br>
<br>
If you offer interface I1 to callers C1, C2, and C2,<br>
and interface I2 to callers C4, C5, and C6, then<br>
you can be sure that C1, C2, and C3 will keep<br>
working as long as you do not make incompatible<br>
changes to interface I1. Similarly with I2.<br>
<br>
Now, moving specifically to OOP:<br>
<br>
Traditionally, e.g. in Smalltalk 80, it was a big<br>
deal that the caller of an instance of a class<br>
does not know the internals of the class.<br>
It only uses methods, and does not look<br>
internally at the instance variables (slots).<br>
<br>
(I can't remember whether ST-80 had the concept<br>
of private methods that are only intended to<br>
be used from methods of the class and not<br>
from callers.)<br>
<br>
OOP was often compared to, or even conflated<br>
with, the concept of "abstract datatypes", in<br>
the sense meant by Barbara Liskov. In CLU<br>
and such languages, similarly there was a<br>
sharp distinction between the advertised<br>
interface presented to callers of the ADT<br>
(abstract datatype, corresponding to a class),<br>
and whatever was going on inside it.<br>
<br>
This was a modularity boundary that allowed<br>
a separation of concerns between the users<br>
of the ADT and the implementation of the ADT.<br>
<br>
Recently, this was considered such a big deal<br>
that Liskov was awarded a Turing Award.<br>
<br>
ADT's did not, per se, contain the concept of<br>
inheritance. Inheritance was first exposed to<br>
the general public with ST-80.<br>
<br>
However, there wasn't even a semblance of<br>
an effort to provide any modular separation<br>
between a class and its subclasses. So,<br>
whenever the implementation of a class<br>
changed in any way at all, you risked<br>
breaking subclasses. This was particularly<br>
a problem when library 1, under control<br>
of group-of-people-1, provided a class,<br>
and library-2 subclassed it. If a new<br>
release of library-1 came out, there was<br>
in general no way for g-o-p-1 to find<br>
everybody who had subclassed their<br>
classes; if the lib-2 people installed<br>
the new release of lib-1, they had<br>
no idea whether anythig would work.<br>
<br>
Now, you could just say that there should<br>
be internals and externals, and the externals<br>
exposed to the callers and the externls<br>
exposed to the subclassers are exactly<br>
the same set.<br>
<br>
This does not work for most non-trivial cases.<br>
I will assume that you know why, since I can't<br>
explain it briefly.<br>
<br>
So, what I am proposing is to be explicit<br>
about what is being exposed to the<br>
subclassers, so that if the base class<br>
is changed in a new release but<br>
the subclasser interface is compatible,<br>
the lib-2 people can rest assured that<br>
their library will continue to work.<br>
(Unless there are bugs, of course.)<br>
<br>
In C++ and Java, this isn't done with<br>
Lisp packages, of course. The "public"<br>
members are the interface to the caller,<br>
and the union of the "public" and "protected"<br>
members are the interface provided to<br>
the subclassers.<br>
<br>
Whether the subclassers should be given<br>
permission to override the public things,<br>
in all cases, is an interesting but separate<br>
discussion. With Lisp packages, you<br>
can control this any way you want.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite"><br>
<pre wrap="">
We may note that "protected" is actually public, in the sense
that when we specify something as "protected", we specify
that the library has external clients which can rely on this protected
method or field.</pre>
</blockquote>
In that sense, yes, absolutely.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap=""> Anyone may inherit from our public class, and
access the "protected" members, therefore these members are
available to public. If we change the protected member, we affect
the library clients.
</pre>
</blockquote>
What I'm doing, however, is to distinguish<br>
between two sets of "public", as explained<br>
above. The callers, which would be a<br>
"big public" (lots of callers) must cope<br>
with incompatible changes relatively<br>
less often, whereas the "small public"<br>
(those who subclass) must cope<br>
relatively more often since more is<br>
revealed.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">This drives me to a conclusion, that a single language feature is sufficient
which allows to separate a protocol for interaction with a module
from the module part we expect to change without affecting clients.
</pre>
</blockquote>
Taking you literally, we do not need a new CL feature.<br>
But translating what you're saying into the terms<br>
I am using, you're saying that we need only one<br>
protocol, whereas I am saying that it's better<br>
to have two. There is no "language feature"<br>
at the CL level, but there is a practice, or<br>
a "design pattern", that I am recommending.<br>
Having :documentation in the defpackage<br>
to explain what's going on, especially who<br>
is intended to use this packge, would be<br>
very hepful. Design patterns are essentially<br>
a way to extend a language (in a nutshell).<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">I made observation on many java systems, that addition to packages
the public/protected/private for classes has bad influence on the
system modularity.
Many java programmers tend to hide attributes of every single class
behind get/set accessors, even for simple classes which just hold
values passed between methods and do not contain any logic; to
create hierarchies of interface/abstract class/concrete for various
minor classes, employing protected methods.
</pre>
</blockquote>
There are at least two reasons to put in such methods.<br>
<br>
<br>
First, changing the implementation while keeping<br>
compatible behavior for the public methods.<br>
<br>
Imagine that you have a class called Point representing<br>
a point in two-space. You could use Cartesian<br>
representation: two data members x and y,<br>
and getX and getY (and, if desired, setX<br>
and setY). These are the simple getters<br>
(and setters) that you mention above.<br>
<br>
But what if, for some reason (numerical<br>
methods, I don't know) you decide that<br>
internally using a polar representation,<br>
with two data members storing an<br>
angle and a distance from the origin, is<br>
better. You can make getX continue<br>
to work using the appropriate<br>
trigonometry operations.<br>
<br>
Second, these days there are lots of tools<br>
that use "dependency injection" and whatnot<br>
that only work if you have such methods.<br>
Extending "ant", using Spring, and so on<br>
work this way, so it has become part of<br>
the usual Java design pattern for many<br>
classes. (See "Java Bean".)<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">But at the same time, people do not care to create structure at larger
level, to divide the system into modules. It is not uncommon to see
large systems where all these classes, subclasses in all the
packages are public: everything is available to everything.
</pre>
</blockquote>
Sure.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">Separate access control for classes obscures the idea of modularity
(especially in case of such an OO centric language like java, the
programmers are mostly concentrated on classes/object, and often
don't even think about packages;).
</pre>
</blockquote>
I don't know what you mean by this. It depends what<br>
you mean by "access control". But if you mean limiting<br>
the access that callers of a module have, that is<br>
exactly the way modularity is usually realized.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">Class is too small entity to form a module. A module API (protocol)
usually consists of set of classes, methods, factory functions, maybe
some global variables.
</pre>
</blockquote>
Ah, yes. That's why Common Lisp has packages and<br>
Java has namespaces; to be able to make groups<br>
exactly as you are saying.<br>
<br>
<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">Another thought is that the interface between base class and
its subclasses is not a second interface, but a part of the first interface.
As you said:
</pre>
<blockquote type="cite">
<pre wrap="">So we could have one package
for the code that calls into our library, which would have the usual
protocol, which we can call the "external protocol". Then we could
have a *second package*, which presents a second protocol that
subclases would use!
</pre>
</blockquote>
</blockquote>
The second package IS for the second interface!<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap=""><!---->
What would be the name for the second protocol? I.e. what is the
interaction the base class and the subclass perform via this protocol?
</pre>
</blockquote>
I'm not sure what the name would be. If we were<br>
to adopt the practice I'm advocating, it would<br>
indeed be a good idea to have a standard<br>
naming practice.<br>
<br>
If you look at some of the major Java libraries, you<br>
can see them dealing with that. For example,<br>
look at JNDI, the standard Java interface for<br>
dealing with any kind of naming service,<br>
particularly hierarchical ones such as file<br>
system directories and LDAP servers.<br>
<br>
First, there is what they call the "API".<br>
This is used for modules that want to do things<br>
like "look up this name and tell me the contents"<br>
or "for this name, tell me all the children".<br>
<br>
Then there is what they call the "SPI",<br>
the "Service Provider Interface". In the<br>
API, the calling module calls JNDI.<br>
For the "SPI", JNDI calls the service<br>
provider module. A service provider<br>
module is what is often called a "driver".<br>
You'd have one for file systems, one for<br>
LDAP, and so on. Java comes with some useful<br>
ones like those two, and you can add your<br>
own if you want to allow people who use<br>
the JNDI API to access some previously<br>
unsupprted naming system.<br>
<br>
This is very much like what I'm talking about.<br>
The API and the SPI are in different Java<br>
namespaces (well, as far as I know),<br>
and writing a module that calls the API<br>
is extremely different from writing a<br>
service provider.<br>
<br>
The SPI might or might not work by overriding<br>
classes or adding :before methods or whatever.<br>
<br>
In fact, the whole thing that I am advocating<br>
here is NOT ONLY for OOP and subclassing.<br>
I just presented it that way because that's<br>
where I see the main "pain point". What<br>
REALLY matters is the distinction between<br>
the API and the SPI.<br>
<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">As you point, it may be reusing of the implementation (derived streams
reuse write-string implementation from the base class).
Looks like a thing intended for reusing can rightly be called
an "external protocol" too.
</pre>
</blockquote>
Well, this is something different, I think; a utility<br>
class whose behavior has to be documented.<br>
But this is a side issue and this email is<br>
alarmingly long already. :)<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">Another view on the interaction in subclassing is that the base class serves
as a template of some functionality, and we can customize its logic by
overriding some methods. </pre>
</blockquote>
In Java, however, the two are separated: there is an<br>
Interface that specifies the contract, and then<br>
there might or might not be a standard abstract<br>
base class that provides some helpful stuff.<br>
You are not required to use the utility<br>
abstract base class, although in practice I<br>
think I've always seen it used.<br>
<br>
Java allows you to skip having the Interface,<br>
which is too bad from the point of view<br>
of clean and simple language semantics,<br>
and for clarity of code. It's a lot like<br>
CLOS's not requiring defgeneric, and<br>
probably for the same reason; to let<br>
you be lazy or more succinct. But I<br>
think it's less clear. I try to always use<br>
explicit defgenerics. In our own code<br>
here, we particularly stress using<br>
defgenerics for functions that are felt<br>
to be exposed to other modules.<br>
(I say "felt" because our code does not isolate<br>
modules as well as it ought to.)<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">The output stream example may be viewed
in this perspective: we plug-in our write-character implementation into
the functionality implemented by the base class in order to customise it
to work with different character source.
</pre>
</blockquote>
Yes.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">The means to parametrize/customize the protocol behavior can also
be considered as a part of the protocol. In simple case it's method parameters,
in more complex case we provide, for example, custom strategies, and can do it
by defining a method for the sublcass.
</pre>
</blockquote>
OK.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">Therefore it looks to me that in many cases we deal with a single interface,
not two distinct ones.
</pre>
</blockquote>
Well, I think I've explained my point about that above.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">Sometimes a module can interact with the outside world via several protocols, but
it not necessary relates to sublcassing, and it's not necessary that both (all)
the protocols are defined by this module.
</pre>
</blockquote>
Yes, indeed! That goes beyond the scope of what I've<br>
said so far. You can indeed have more than one external<br>
API, regardless of what you do with SPI's.<br>
<br>
I belive Ada lets you do all of this. More about<br>
Ada and the experience with compatible<br>
upgrades, below.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">Now, there's a great thing about CL packages: you can have more than
one defpackage for the *same* symbols. \
</pre>
</blockquote>
</blockquote>
Exactly. You can have more than one API, you can<br>
have a separate SPI, you can have multiple SPI's<br>
and so on. This is crucial to everything I am<br>
proposing. (By "proposing" I do not mean to<br>
claim that what I'm saying is novel and original.<br>
It may well have been done before. I'm not trying<br>
to take credit for anything here.)<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap=""><!---->
It's a great feature. I think you mean something like when we want to define one
protocol as an extension of another protocol. Although in many cases I suppose
it's possible instead of extending interface to have a separate interfaces. I.e.
if one API is (func1, func2, func3), and another API is (finc1, func2, func3, extra-func),
we could have the second API just as (extra-func).
</pre>
</blockquote>
Exactly.<br>
<blockquote cite="mid:133601291688839@web147.yandex.ru" type="cite">
<pre wrap="">A good example is needed. Maybe something like database connection API, where implementation
for particular database is provided by a pluggable "driver"; or maybe swank, and swank
backends for different lisps; or something simpler.
</pre>
</blockquote>
Right, exactly, as I discussed above.<br>
<br>
For your reading pleasure, here's is some stuff<br>
about Ada. It's from Tucker Taft, one of the<br>
world's foremost experts on Ada (no kidding).<br>
Note that Ada 95 is a later version of Ada,<br>
with improvements to the original Ada<br>
definition. Tucker was very heavily involved<br>
with the definition of Ada 95, for years.<br>
<br>
The point he makes in the first paragraph<br>
corresponds to what I've been saying:<br>
the fact that "print" calls "to_string" is<br>
NOT apparent to the caller, but IS<br>
apparent to anyone writing a subclass.<br>
<br>
----------------------------------------<br>
<br>
<br>
</body>
</html>