Let me clarify a previous statement that probably was misleading:
[EMAIL PROTECTED] wrote:
>
> 2) Java draws a sharp distinction between code and data. REBOL,
> as a pure von Neumann language, refuses to recognize that
> distinction. It is trivial to write REBOL code that modifies
> itself, or that creates a new function (or just a block) at
> run-time, and subsequently evaluates/executes that newly
> constructed expression. I know of no reasonable mechanism in the
> JVM that allows running JVM bytecodes to manufacture new content
> for the runtime constant pool (which is where symbolic references
> to classes, methods, method signatures, etc. are stored).
>
> An example of an unreasonable mechanism would be for the running
> code to compose an entirely new class file on the fly, then
> invoke the class loader on that new class file. I believe the
> overhead of such an approach would be intolerably high for any
> practical uses.
>
It's not actually necessary to write the class file to disk and load
it back from disk. A ClassLoader can take bytecode from an array
in memory.
That detail wasn't my main point -- which was that manufacturing
new classes on the fly would be a terribly inefficient way to
handle the REBOL concept
florp: make object! [
; etc...
]
glompfh: make florp [
; more etc...
]
However, I don't want to risk making bogus arguments, in fact or
appearance.
-jn-
--
; Joel Neely [EMAIL PROTECTED] 901-263-4460 38017/HKA/9677
REBOL [] print to-string debase/64 decompress #{
789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC
B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}
