Alessio said:
Do a field named foo and a method named foo in the same class collide
in Java? No.
Because they reside in different namespaces. Java doesn't just consider
them both "symbols" and throw them together into a single namespace;
instead, it creates separate ones within the class for fields and for
methods.
However, an earlier poster said that Common Lisp just considers method
names and the like to be "symbols" and throws them all together into a
single namespace per package.
If that earlier poster was incorrect, take it up with him. Attacking me
for simply quoting him is pointless, rude, and should make you feel
guilty now that you realize the attack was aimed at the wrong target and
you just smacked an innocent bystander for someone else's offense.
My example was meant to show all the possible combinations, not
suggest they usually are all used.
Well, I was simply considering the possibility that they ARE all used,
and it seems that using two of them causes problems.
See the parameter name - it's transaction-manager.
What parameter name? All I see is a list of arguments. A
transaction-manager and a picture-library might conceivably both be
arguments to the same call.
The "natural encapsulation" is only natural in Java, C++ and languages
with a similar kind of OO. It's not the only possibility. In Lisp, the
natural encapsulation is at the package level
My point was that Lisp's encapsulation granularity is much fucking
coarser!! Are you fucking dense?
Sure, this is a possible problem.
Thank you for admitting the truth at last.
I know you probably won't believe me, but it does not happen frequently
Ridiculous.
no more than it happens in Java with two classes of the same name.
There are only a few class collisions in Java's standard library. I've
mentioned javax.sql.Date and java.util.Date before.
If methods could collide, there'd be 17,392 collisions of them (counting
N of the same name as N^2 collisions; if N-1, it's "only" a couple
thousand; in neither case counting polymorphic overrides as colliding
with the overridden version(s)). The names "close", "dispose", "next",
"readResolve", and "writeExternal" are particular culprits.
Stick THAT in your pipe and smoke it.
T is the canonical way to represent true. Historically it has also
been used to designate the root of the type hierarchy - the type of
all objects - and naturally it has been used to designate the root of
the class hierarchy, too. Don't ask me why. Surely it does no harm
This is what lack of a REAL type system gets you: one object doing
triple, quadruple, even quintuple duty. Jack of all trades, master of
none. (This last can also be a criticism of emacs.)
As damning as when the same line is spoken on TV by a politician.
Heh, Graphics2D is really an example of what I was saying

it has
drawPolygon, drawOval, drawText, and a few other drawSomething. What
if I wanted it to draw the cool chart generated by my favourite
library?
The chart would be an instance of some class, say Chart, implementing
the other interface, the one with a drawOn(Graphics2D) method specified.
The drawOn() method would call the Graphics2D methods. Code that wanted
to draw a chart on a Graphics2D would call the chart's drawOn() method
with the appropriate parameter. Different chart instances would produce
different drawings.
But if you confuse your personal preference with objective
truth, and write that "truth" in public, I - we - feel the need to
correct your claims.
That statement makes several insulting and false insinuations about me.
I'm sorry, but I genuinely think [repeats insults]
Think what you want, but please restrain the urge to blurt out uncivil
things in public. Weren't you taught any manners as a child?
I don't think
That needs rectifying right away, then.
If I write MY:frobnobdicate specialized on YOUR:quux, I'm not altering
the behavior of MY:frobnobdicate specialized on other objects.
Cop-out. Are you or are you not altering MY:frobnobdicate?
I'm adding a possibility, not changing behavior.
You are changing behavior. Suppose I had code that passed a quux
superclass object around, gotten from somewhere, and called
MY:frobnobdicate on it? Add the quux class and pass one to my code, and
its behavior changes. Not because you subclassed my class to make quux
and put a polymorphic method in YOUR:quux but because you subclassed by
class to make quux and put a polymorphic method in MY:frobnobdicate!
See the difference? In Java you put the method in your own class. In
Lisp you put it in MY generic function. Mine, I tell you, mine!
This seems a minor wart. Until you have experience working in a large
development effort with many many people involved, and this inability to
fence off parts of things goes from wart to colossal headache.
[snip]
Poor analogy. Once again, you are subclassing under a new name instead
of changing the original. Because that's what Java does. It supports
exactly the kind of modularization and localization of code changes that
Lisp doesn't.
Viewing one as a list and the other as a tree (class hierarchy)
A simple strategy: when an apples-to-apples comparison makes your side
look bad, rebut by comparing apples to oranges instead!
there's-only-one-way-and-it-is-not-optimal is a real possibility, too.
That's why it's better to find a happy middle:
too few ways too many ways
BASIC FORTRAN Pascal Java C++ Lisp perl
defgeneric DEFines a GENERIC function.
cl is shorthand for common-lisp, and foo... well, it's foo
I know this. The point is, the names are less SELF-explanatory. (And you
omitted to state what the #: bit is for the latter.)
I had been being sarcastic about code readability.
[quite a lot of untrimmed-but-unused quoted material now trimmed]
Mind you, I usually refrain from saying something is absolutely
"superior" because there are really many dimensions to be considered
Good good.
Ah, there's always a "but", isn't there?
I do think [subjective opinions and stuff]
Which I'm sure are absolutely fascinating, but which prove nothing in
this debate.
I also think Java has a lot of nice features which probably many
lispers don't know about. Built-in serialization is one of those, for
example, as is the nice integration of URLs into the language, the
collections framework, ...
The URLs leave a thing or two to be desired. For one thing they're not
integrated, there's just a standard library class for 'em, and OOTB it
only works with HTTP and one or two other things, one their own
Java-specific jar: protocol.
I don't think they should be integrated more than that, mind you, but
there's some warts, like MalformedURLException's handling (and more
generally, illegal argument exceptions should not be checked
exceptions!) and some awkwardness with certain patterns of use. Just
constructing a URL triggers some behavior beyond mere construction,
unlike a File abstract pathname object, which I disagree with.
Constructors that do more than construct are evil.
Maybe that's the reason I'm using, and sometimes contributing to, a
Lisp implementation running on the JVM...
Clojure?