So now you're disagreeing with *yourself*? Well, I guess you might
sometimes change your mind about one of these things, but still, the
timing in this case was atrocious!
But it wasn't. Or else the later one wasn't correct. You can't have it
both ways! Either they all go into one name-resolution pool or they
don't; they can't both do so and not do so at the same time.
So, the earlier post WAS incorrect.
Not consistent. Either the former or the latter is false. I think you
have package and namespace confused, and the package actually has a
separate namespace in it for each of several kinds of thing. In other
words, it doesn't just have symbols, it has methods separate from
variables separate from classes etc.; it has some notion of which of
these is which and keeps them tidy.
No, I don't. Packages in Lisp are name-spaces: spaces of names, sets
of names. They contain - names. Just names, nothing else. Really.
Names can refer to many things. They can have many meanings attached.
But those meanings are not attached using packages.
The same is true in Java, somehow, too: if you use a Class as a
namespace (classes are indeed namespaces in Java, though not the only
kind of namespace).
class.getField("foo") returns a field, class.getMethod("foo") returns
a method, yet the name is always "foo". See? Lisp works like this.
When in Lisp you use the symbol foo where a variable is expected, the
compiler uses foo as a variable name; when you use foo where a
function name is expected, the compiler uses foo as a function name;
and so on. But foo is always the same symbol, the very same object.
Java on the other hand has "packages" which are namespaces, but also
are a sort of "logical directories" that contain resources (typically
classes). Lisp is not like that at all.
An admission of the truth at last?
I'm using "namespace" improperly here, in hope to make things clearer
to you. Probably it's more correct to say there are more symbol-to-
object mappings.
By "problems" in this instance I meant scoping headaches for the
programmer, rather than actual failures of the code.
Ok, but this case is like if you had, in Java,
a.X.method(a.Y thing)
a.X.method(b.Y thing)
b.X.method(a.Y thing)
b.X.method(b.Y thing)
used in the same file; not very probable (and exactly as problematic
in Java as in Lisp).
[snip]
Oh God, it just gets worse and worse! Now you say your system's bollixed
up enough that you can't even have, say, a private variable named foo
and a public method named foo in the same place? Who thought this up?
Why would you make private apply to everything of the same NAME,
regardless of whether that name was overloaded? Why?
It's the price you have to pay for having a general naming mechanism
like packages. It's not really a big price, since I've never come up
with a case where it actually gave problems. Naming conventions help,
of course (e.g. variables are usually named *variable-name* with
asterisks).
Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
end of the matter. There's really little point in continuing this.
If you think so.
It's spelled "****". With an F.
Let's tick things off shall we? One. More. Time.
1. Your module size is like in C, a few per program (plus libraries'),
rather than like Java or even C++, one per class.
Imagine C++ only with "private" visible to everything in the same
.cc file, or all pairs of classes in a single source file implicitly
mutual "friends".
C does not have namespaces IIRC. If it had, then yes, CL would be
similar to C (but with the huge benefit that symbols are first-class
and you can manipulate them at runtime).
2. The encapsulation is extremely weak even so. Not only can you
circumvent it by adding a single colon to a scope operator somewhere,
a) it's right next to another colon, so an easy typo to make simply
by bouncing a key;
No, since you have to type the symbol name, so you have to add a colon
AND mistype the symbol name so that accidentally you hit an existing
private symbol - quite unlikely.
b) you can presumably automate even the one lousy extra colon using a
macro;
No, you can't, since symbol resolution is done at read-time, before
macros are expanded.
and c) it will look enough like normal to
be easily overlooked and mistaken for innocent code, unlike, say,
Java reflection and setAccessible(true) calls. Heck you can even get
your Java IDE to find all setAccessible calls on reflection API
objects without false positives and throughout the code base, if your
IDE is decent enough. Meanwhile :: is a search that will have false
positives I guarantee it. All two-or-less-character searches do.
Yet it never gave me problems. Because it's not easy to make a mistake
(see above).
Technically nothing since they're both Turing complete. But much that is
decent and good in Java would require implementing a Java emulator in CL
to get in CL. (The JVM spec is readily available, so this should be
trivial right?)
Ok, turing-equivalence apart, I meant with current Java and CL, and
I've shown you, too.
Class-granular "private" comes to mind in particular.
You have it. Just make the slot name private.
Exactly my point. It works differently, and in this case, differently =
worse. Now every unrelated pair of "close" methods collides, unless you
start being creative with your thesaurus, and then code gets less
readable and there's more and harder memorization to learn to use the
darn thing.
The one for iostreams.
What about closing windows? Oops, no windows, forgot.
Well, I'll
think of *something*...
Those about closing windows are different verbs, yes. There are not
many cases like this. How many more totally unrelated things can you
close?
No you're not, not one damn bit.
I meant WRITING IN ALL CAPS.
I'm sure the guys down at Bellevue that think they're Napoleon think the
same thing when they try to get people to believe them.
yeah, right...
That's not a workaround. We can also have Circle.drawOn, Rect.drawOn,
etc. if we want to be able to do them all consistently. Or we can add a
generic draw() to Graphics2D that takes a Drawable and just calls
argument.drawOn(this). (Assuming we control Graphics2D.) Then you can
happily do graphics.draw(chart).
Why? You're the one designing the system, hypothetically.
Why? The system's designed would make Drawable public, and an interface
so any class could implement it regardless of constraints on its superclass.
What if I want to draw something I didn't wrote, and whose author
didn't know about my Drawable interface?
The cost of having this is that you can change someone else's code, and
even are encouraged to. If they didn't make their class Drawable, why,
you'll just do it for them!
Sure, and what's the problem? I don't change their code, I write new
code which happens to use their class.
[snip]
Not explicitly! And not really at all; the classloader builds up a
dispatch table at runtime.
The classloader does it for you then. The effect is the same.
And I'm telling you, it doesn't quite work.
NO, IT ISN'T! If you still don't understand why I'm afraid you never
will. It's time to drop this line of debate.
For the last time:
--- Lisp ---
(defgeneric f (x))
(defclass c () ())
(defmethod f ((x c)) 'default-value)
BEFORE adding a method for class d:
(f (make-instance 'c)) ==> DEFAULT-VALUE
AFTER
(defclass d (c) ())
(defmethod f ((x d)) 'ok)
(f (make-instance 'd)) ==> OK
(note that the class name D can be in MY package while the name of the
generic function F is in YOURS)
--- Java ---
BEFORE
class C {
String f() {
return "DefaultValue";
}
}
C c = new C();
System.out.println(c.f()); //Prints "DefaultValue"
AFTER
class D extends C {
String f() {
return "OK!!!";
}
}
C c = new D();
System.out.println(c.f()); //Prints "OK!!!"
--------------
The only differences are that, in Lisp,
1. you can define the new method after the class and not necessarily
together with it,
2. you have multiple dispatch, but in this example it is indifferent
since the argument is only one.
Don't be confused by the name "method", which means a different thing
in CL than in Java. A lisp method is a particular specialization of a
generic function: a generic function having one more method in Lisp is
like a method having one more override in Java.
I once knew a guy who was of the opinion that the earth was flat.
LOL.
"Read syntax"?
Yep. An instruction for the Lisp reader.
Ok, that's good.
[snipped some tangential rant about things not in Java's standard
library]
HAHAHAHAHA! How is the sentence "No, ABCL" calling you a liar?!? We're
going into total madness here, boy! I'm a really stubborn guy, as the
poor people reading our posts have noticed (well, those who haven't
still put us in their killfile), but even I am getting tired!
