Yes.
The fact that defmethod is a macro does not mean it remotely
modifies any code.
In and of itself, you are correct: it does not. However, I did not
base my remarks solely upon its being a macro. I also used your own
statement that it could be used to add more dispatches to the dispatch
table from anonymous.c.lisper. Taken together, those statements imply
that this particular macro can and does modify code.
So either it can, or you are incorrect about it adding more
dispatches, or you are incorrect about it being a macro.
What you mistakenly see as "tables"
I do not. I correctly see them as tables.
The code at issue is:
This is quite clearly tabular data and anonymous.c.lisper himself
stated that it controls the dispatch of frobnobdicate method calls.
These observations, taken together, suffice to imply that it is a
dispatch table.
You can write no such "table" as you name them, and write a bunch of
defmethod forms instead - it's the same.
If you did that, then where would the macro put the dispatches?
The real "dispatch tables" are not apparent in source, like they
are not in Java: they are state maintained in the system's
internals, just like in Java, C++ etc.
If this were true, then the defmethod macro could not function in the
manner claimed. The macro can only replace source code with other
source code at compile time. For it to modify a dispatch table,
therefore, that dispatch table must be located in the source code. Its
only alternative is to generate run-time instructions to allocate and
construct dispatch tables, which has two consequences:
1. How are many uses of the same macro with the same method name
throughout the code base to coordinate? They must create and use a
single dispatch table, not one each, for that sort of scheme to
work.
2. The dispatch tables are then being "faked" using ordinary
user-accessible run-time data structures, rather than being true
dispatch tables analogous to Java's or C++'s, which the compiler
and runtime generate and use and which are not user-accessible,
except, in C++, via unwise pointer manipulation. In particular,
the Lisp dispatch tables would not be "state maintained in the
system's internals, just like in Java, C++ etc."
Where is it written that it *silently* works incorrectly?
Two levels above:
This implies that it will quietly do what is unlikely to be what the
programmers intended, without generating any overt warning or error
message. This is commonly called "failing silently". Instead of a
prompt diagnostic, the result is a logic error in the program, and a
greater amount of effort needed subsequently to debug this error.
All implementations I know of warn the user in case of redefinition of a
method.
That contradicts the previous, quoted statement about it "just"
overwriting a method.
I make no sense of this. I'm only able to understand that your notion
of "package" is something that has no resemblance to what a package is
in Lisp.
If that is the case, it can only be because Adlai was inaccurate in
describing packages to me.
A package is a container of symbols, period. I repeat myself:
a package does not concern itself with functions, classes, variables,
methods, etc. etc. etc.
This is contradicted by statements made elsewhere by yourself and
others, particularly, one claiming that a function and a class in the
same package can share the same name. If the package did not
distinguish among these, then that could not be the case.
Still makes no sense to me...
Since that is based on a description of Common Lisp package behavior
that Adlai posted, you should endeavor to figure out which one of you
is apparently mistaken about packages. At this time I have no basis
for choosing either of your interpretations over the other.
What is a public generic function? What is a public class? What is a
private method?
Public = exported. Private = not exported.
I did not state otherwise.
*symbols* in a package can be internal ("private") or exported
("public"). No other kind of Lisp object I know of, besides
symbols, bears the concept of "public"/"private".
Perhaps not directly. But to make a distinction between a method being
private or its name being private seems to be to make a distinction
without a difference. There is a Java analogue:
private static final Integer ANSWER = Integer.valueOf(42);
One would say that the name ANSWER is private, but also that the field
was private. Which it is. It is true that one could get a reference to
the Integer object passed around, so the object itself is not private,
but the field is.
With a private method and methods as first class objects, one would
expect that the method could not be gotten from outside via its name,
but could be via direct reference if one were to obtain one.
Furthermore, in
private class Foo implements Runnable {
public void run () { ... }
}
it may possible to get ahold of a reference to an instance of this
class, though it is private, into a variable of type Runnable. From
there, the run method could be called. The class being private, the
run method is effectively not exported, but it's still callable,
through polymorphic dispatch.
So whereas there is arguably a distinction to be made, in practice
it's a pointless one: "the method is private" is more or less
synonymous with "the method's name is private".
No. To add a method you call defmethod, period. No access to source
required.
You're forgetting that, by your own prior testimony, the defmethod
macro in turn adds the dispatch entry. So whether you do it by hand,
or have the macro do it for you, the dispatch table must be accessible
to you.
Again, no such table exists in source.
Again, macros operate by transforming source, so if this were true,
the defmethod macro could not function in the manner you have claimed.
"to do something that otherwise couldn't be done" is not to be taken
literally.
That is not a valid argument against my reasoning. It is, rather, a
"cop-out". It is also an arrogant presumption on your part, purporting
to be able to speak for gugamilare as you have just done.
No offense intended, but haven't you thought that maybe the
contradictions are between your assumptions and what other people say
to you?
Of course not, since the contradictions in question are contradictions
between a statement made by one of you and a statement made by another
of you. No assumption that I made could alter either statement in any
such case -- you each said whatever you said.
For instance, supposing you were to say that the sky was green, and
gugamilare that it was blue, these statements would contradict,
independently of my own personal opinion on the matter or of any
assumptions on my part.
I took the liberty of trimming a large volume of quoted material that
was left unaddressed, but untrimmed, leaving only a small portion. Was
a part of your post mistakenly omitted?
