Re: export question

["fractals" <fractals@ping.be>]

>At 12:37 PM 7/25/99 +0200, fractals wrote:
>>James,
>>
>>>Writing a tool to do the package renaming wouldn't be terribly hard
either,
>>>although if you're gonna go to that much trouble it might be better to
just
>>>add the feature to MLj yourself, which would be more useful for the rest
of
>>us.
>>
>>Andrew Kennedy is - hopefully ;-) - working on this at the moment.
>
>I thought his message was saying that he was going to fix the bug of it not
>reporting an error message when a package name is given rather than
>implementing the package naming for the exported code.  I guess his meaning
>wasn't clear.
>
>jim

We had a private mail exchange which I'll report here, because I think this
could well be of interest for everyone (I hope this won't hurt Andrew's
feelings ;-))

Andrew:

How would you like the design improved? Bear in mind that there are access
considerations between exported and non-exported MLj classes and external
Java classes. Here's one proposal:

(1) Name a single package for all internal MLj classes.
(2) Allow the export of MLj classes to arbitrary packages (as you attempted)
but only allow private and public access modifiers on fields and methods.

Unfortunately this would force internal MLj classes to be "public", as
otherwise they could not be accessed from the exported classes.

Myself:

I lack some background on the way MLj classes collaborate. For example: are
the ML-supporting classes (with the funny names) always the same, or are
these to be re-generated each time. If they are the same, they could be
generated once and used like a runtime, but you had certainly provided a way
to use this feature, if it existed. OK, I thus strongly guess that the
"compiling whole program" phase performs some kind of "hard linking" (sorry
if the term is not appropriate, but I really don't know much about
compilers) between the exported and non-exported classes. So, there's
something a little bit annoying here: suppose I compile some class one day
and I'm happy with it. Considering your proposal, I would end up with a
class myFirstJob in package myCorp.myBusiness and a set of public,
ML-supporting classes in a package named - for example, com.persimmon.mlj.
The next day, I want to do some other job in MLj, mySecondJob. But if the
"hard linking" rule holds, I will have to recompile myFirstJob along...
Anyway, if the compilation might become lengthy, the functionality is there.
I hope I understood your proposal. Anyway, I don't understand quite well
what you mean by
    "allowing *only* private and public access modifiers on fields and
methods."
I don't know either what's *unfortunate* with the fact that internal MLj
classes be public. Do you mean: for performance reasons or something ?
I'm coming to another proposition, which could be absolutely insane in terms
of memory usage, but more practical for avoiding too lengthy compilations:
suppose I create a class in myCorp.myBusiness, I would end up with
myFirstJob and an automatically generated package myCorp.myBusiness.mlj_rt
with the internal MLj classes. There would be a per-package generation of
MLj-supporting classes.
I hope I'm not completely out of the point...

regards,

candide