On Thu, 28 Oct 1999, Thomas McKay wrote:
> After I asked the question I had some more time to poke around in the Jacl
> src. No, it was never a feature it just seemed natural to me that it would
> be, though.
Are you saying that this "autoload of commands implemented in Java"
feature should be added to Jacl? I am not really sure that is such
a good idea. I take the view the Jacl should try to do things just
like Tcl when possible. Having some snazzy feature that works in
Jacl but not Tcl (and therefore Tcl Blend), seems like a step
backwards.
> I'll include some code snippets below to illustrate what I am doing. This
> was my thought: When a user types a command, say "MyCommand," the interp
> first checks internally for a definition. Not finding it, it calls the
> unknown proc. The unknown proc attempts to resolve the name by first
> attempting to load a class of this name. If found, the class must, of
> course, be an extension of Command. If it's not or the class is not found,
> the unknown proc then treats the command as an executable name and attempts
> to run it. (At this point we're in the original unknown proc provided with
> Jacl.)
So is the point just to avoid the call to java::load? Why do you need
your own Java code, is there something that java::load did not do that
you needed. You can provide a -classpath argument to java::load.
> This works out great, by the way. My application has a interactive command
> line (wish-like). I've named the majority of the commands through the
> Extension feature. However, the user may right their own commands to extend
> the functionality of the application. By removing the need for an Extension
> for every Command, a class name becomes a command name.
The other problem I have with your idea is that it would give people
the impression that putting classes in the default package was OK.
Perhaps a better approach would be to set it up so that people could
indicate "if a command is unknown look for an implementation of
the command with the package prefix X"
So an unknown command "foo" with a package prefix "com.mo.unknown"
would look for a class "com.mo.unknown.foo". You could also have
a list of package prefixes to check for.
The bottom line is that this seems like a feature that you might
want to add to your app, but I do not think everyone would want
it. You can define your own unknown command for your own
application so I would think that would be the best approach
to take. If you define your own unknown and then default to the
system unknown, your feature would work in Tcl Blend too.
Also, you comment about being able to reload a .class file was
a good one. I was already planning on adding something like that
to the 1.3 version.
later
mo
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
