I think you're right. If the reload feature to java::load is there, that
would be a plus. I'll play around a little bit more with java::load too.
I submitted the code snippets more for sharing purposes than to suggest that
it should be in a Jacl release. I enjoy learning from other people's
approaches and thought my code might spark some ideas out there. :-)
> -----Original Message-----
> From: Moses DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 28, 1999 11:28 AM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] loading classes
> dynamically as commands
>
>
> 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]'.
>
----------------------------------------------------------------
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]'.
