Re: CLOS and databases
From: Pete Kirkham (pete-kirkham-2004_at_cafemosaic.co.uk)
Date: 03/20/04
- Next message: David Golden: "Re: Ye Old Time Sharing System"
- Previous message: Chris Hall: "Re: Some advice for a lisp newb"
- In reply to: Erann Gat: "CLOS and databases"
- Next in thread: Erann Gat: "Re: CLOS and databases"
- Reply: Erann Gat: "Re: CLOS and databases"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 20 Mar 2004 18:49:49 +0000
Erann Gat wrote:
> My goal here is not only to make something functional, but also to
> highlight the power of CLOS with something that will really knock the
> socks off the Java people, so I really want to do this the Right Way.
As a lisp liking Java person, here are the points you need to address to
de-sock a Java-head:
Remember in your comparison that the 'Java way' is not REP but making
the program from source files with a build utility, often integrated
with an IDE.
In Java, there is no MOP built into the language spec. (There again, in
ANSI common lisp, ditto). There is, instead, a mechanism for specifying
metadata about packages, classes, fields, and methods, called javadoc.
Javadocs consist of a descriptive string, and certain attribute tags.
This metadata is processed by a separate processor to the compiler, as
part of the build process for the project. Sun provides mechanisms and a
parser for people to extend this metadata by adding their own attributes.
In Java, there is no 'slot-accessor'. Inside a class, the fields are
accessed using the field access primitives. Outside, mutable fields
should be accessed using accessor function pairs. This isn't enforced by
the language, but strongly encouraged by every Java text I've seen.
For example, the class
(defclass foo () ( (foo :type integer) ) )
Would be written in Java as:
class Foo {
int foo;
public int getFoo () {
return this.foo;
}
public void setFoo (int foo) {
this.foo = foo;
}
}
Whereas the version with public field access:
class Foo {
public int foo;
}
Would be used where a struct would be in C, rather than as a full blown
class.
As part of the Java build process, tools such as AspectJ, XDoclet and
the many DB binding tools process either the code before the javac
compiler, or the byte code after. XDoclet uses the Sun-sanctioned
metadata mechanism, for example to using the hibernate DB mechanism the
attribute:
/**
* @hibernate.class
* table="FOO"
*/
Is added to the jdoc, and the doclet processor called as part of the
build process. This adds the function calls to the source code before or
after the property accessors to ensure the
Javadocs are the mechanism where metadata for the elements that are
available in the MOP is stored in Java source code for compile-time
processing. There is a separate mechanism, the reflection API, for
getting metadata at runtime.
After the '@' <java-legal-name>, the syntax is not restricted by the
doclet spec, instead the text to the next @ is returned as a string.
This is to be changed in version 1.5 of java, where user defined @tags
are allowed in the source code proper, and will be available via the
reflection API at runtime.
The processors that process the compile-time metadata are not specified
in the language, but Sun provides a framework to add them to. The build
process itself is not specified in the language, but one build tool,
Ant, is ubiquitous.
[java head off: It is a less than good thing that the only extension
mechanism in java (version<=1.4) is by adding to the jdocs, and that
jdoc sections are tagged in a manner such that the javac compiler
re-uses the /* to ignore, allowing people confuse them with comments.]
Using a freely available DB binding framework (hibernate), the
'standard' java build tool (Ant), the Java language's metadata mechanism
(doctags) and an implementation of a doctag processor (XDoclet), what is
needed to implement the functionality in Java is
- one XML element added to the build script to invoke the metadata
processor.
- two lines of metadata added per class to specify the database table.
That is what is the 'competition' is for this kind of functionality in a
typical Java development environment. Much as I like the REP loop, I
don't believe that for commercial scale development lispers don't use
build scripts. The difference being that the scripts are in the same
language, and the metadata is in the same syntax, and available at
runtime in a consistent manner.
Ultimately, as frameworks for binding Java classes to DBs are at an
advanced state of functionality, and have all the transaction queuing
etc. sorted, I think the case for lisp in this comes down to:
- one step compile has real advantage over separate build steps in a
script
- one syntax for metadata, build script and program better than
distinct syntaxes
and maybe:
Metadata available in consistent manner at runtime
Though for the simple 'persist to db' cases the metadata isn't required.
As for 'ease of use to a typical programmer who can use the available
tools', 'number of lines of code to do it', or 'impact when retro
fitting to existing app' don't seem to be where you can gain in this use
case.
Pete
- Next message: David Golden: "Re: Ye Old Time Sharing System"
- Previous message: Chris Hall: "Re: Some advice for a lisp newb"
- In reply to: Erann Gat: "CLOS and databases"
- Next in thread: Erann Gat: "Re: CLOS and databases"
- Reply: Erann Gat: "Re: CLOS and databases"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
