Editing Rich's planning pages?

6 views
Skip to first unread message

Chas Emerick

unread,
Jul 24, 2009, 10:57:35 PM7/24/09
to cloju...@googlegroups.com
Rich:

I'm wondering to what extent project members should feel free to add
notes/suggestions/thoughts/etc to wiki pages you're using for
planning...? In particular, your recent edit to the newnew page
("Optional name for class?....Why?") is crying out for documentation
of some key use cases. I'd be happy to bother you in irc if you
prefer (;-D), but I thought you might appreciate such things to be
persisted to the wiki (perhaps appended to your main outline, so as to
not clutter things?) so that they're not so transient.

Cheers,

- Chas

Rich Hickey

unread,
Jul 25, 2009, 7:56:18 AM7/25/09
to cloju...@googlegroups.com
I would prefer people not edit my planning pages. They are my notes,
and public so that people can see what I'm thinking about. If they
were to become a dialog about features it would become a mess and no
longer useful to me. We have two Google groups and an irc for
discussions - let's please use those.

Thanks,

Rich

Rich Hickey

unread,
Jul 26, 2009, 10:35:03 AM7/26/09
to Clojure Dev
So, what are your use cases?

Rich

Chas Emerick

unread,
Jul 27, 2009, 7:12:11 AM7/27/09
to cloju...@googlegroups.com

On Jul 26, 2009, at 10:35 AM, Rich Hickey wrote:

> On Jul 24, 10:57 pm, Chas Emerick <cemer...@snowtide.com> wrote:
>> Rich:
>>

>> In particular, your recent edit to the newnew page
>> ("Optional name for class?....Why?") is crying out for documentation
>> of some key use cases.
>>
>

> So, what are your use cases?

(Unsurprisingly,) they're all interop-related:

(1) optional static names are necessary to support (transparent) use
of clojure-authored APIs from Java and other jvm languages. Perhaps
you're aiming to have genclass continue to be the sole source for this
sort of functionality...

(2) Far more important is big-S Serialization interop, and all that
depends on it: OODBMSs, ORMs, and stuff that uses RMI like various JMS
implementations, clustering tools (shoal et al.?), J2EE session
storage, etc. Right now, clojure data structures are mostly
transparently serializable (thanks to AFn implementing Serializable),
except for a couple of edge cases (off the top of my head, keyword
interning).

Losing reliable, static names for those data structures would blur the
interop story in this area -- perhaps requiring falling back to
readObject/writeObject impls that use print-dup? I'm not super-
familiar with those readObject/writeObject methods, and using print-
dup may end up being much preferable in general, but it's an issue
worth thinking about.

Cheers,

- Chas

Rich Hickey

unread,
Jul 27, 2009, 8:19:32 AM7/27/09
to cloju...@googlegroups.com

Since newnew is largely about usage similar to Java anonymous inner
classes, I'm confused about these requirements, as you wouldn't get
either of these from an anonymous inner class. Class names for direct
consumption (i.e. via ordinary lookup/linking) must be static. It
really is that simple, and true of all Java. So, yes, gen-class is
still going to be the way to create named classes for consumption via
Java.

I've thought a little about these dynamic class-generating mechanisms
perhaps creating .class files in designated directories, thus allowing
them to be loaded by ordinary classloaders higher in the chain, but
even then there are still issues (in addition to the obvious
file-writing privileges), e.g. if a generated class depends upon
classes visible to some child classloader but not a parent loader.

In the early days Clojure tried to maintain a single-world-view of
class visibility, with a shared dynamic loader, add-classpath etc.
This has served it very poorly, with conflicts due to the inability to
proxy Class.forName, inability to expose dynamic classes through
parent loaders, conflicts with modularity systems like OSGi,
NetKernel, Tomcat and NetBeans etc. It can appear to work in the
'Clojure consumes but is not consumed' cases, but doesn't really.

So, no more pretending. If you want a class name to be visible you
must compile a .class file and put it in the classpath. That works
everywhere, is compatible with every classloader hierarchy, every
tool, and every modularity system.

If someone with some serious knowledge of classloaders and modularity
systems has a clever idea for this, I'm open to suggestions, but
that's the current thinking.

Rich

Chas Emerick

unread,
Jul 27, 2009, 3:04:51 PM7/27/09
to cloju...@googlegroups.com

I would agree with just about everything above. Being able to
reliably Serialize clojure objects (including core collections) seems
like a critical piece of interop, though, especially given the breadth
and depth of Serialization in existing APIs (many of which I think
we'd all consider "core" in various applications).

newnew is clearly a moving target, but I just wanted to put
Serialization and its requirement for static names on the table as a
key concern, insofar as newnew is going to be the preferred way of
defining data structures. Whether it is itself capable of defining a
static name, or whether that functionality remains in gen-class or
some simplified version of it is mostly irrelevant to me (and likely
above my pay-grade).

Cheers,

- Chas

Reply all
Reply to author
Forward
0 new messages