Title: Java -> elisp communication (was RE: BanInfo wizard anyone?)
Hi Nick,
> > >> The translation layer could handle things like the java method
> > >> signature returning, say, a hashmap. The layer could have a
> > >> hashmap to alist conv
> From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 09, 2002 11:46 AM
> To: Nick Sieger; Galen Boyer; [EMAIL PROTECTED]
> Cc: Graham Bennett
> Subject: Java -> elisp communication (was RE: BanInfo wizard anyone?)
>
>
> Hi Nick,
>
On Mon, Dec 09, 2002 at 01:50:59PM -0600, Nick Sieger wrote:
[ snip ]
> That's a valid point. When I examined the three sourceforge-based
> java refactoring tools available (JRefactory, Transmogrify and
> Freefactor) I liked the way Transmogrify was designed the best (but
> maybe I didn't look c
Nick Sieger writes:
> > From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, December 09, 2002 11:46 AM
> > To: Nick Sieger; Galen Boyer; [EMAIL PROTECTED]
> > Cc: Graham Bennett
> > Subject: Java -> elisp communication (was RE: BanIn
Title: RE: Java -> elisp communication (was RE: BanInfo wizard anyone?)
Hi Paul,
I think that in the case of Transmogrify we didn't have much choice. We wanted to interface with an engine and an interface that was already defined, so we could not change the control flow to us
Nascif Abousalh-Neto writes:
> Hi Paul,
> I think that in the case of Transmogrify we didn't have much choice.
> We wanted to interface with an engine and an interface that was already
> defined, so we could not change the control flow to use queues and even
> handlers. Maybe an adaptatio
> "GB" == Graham Bennett <[EMAIL PROTECTED]> writes:
[...]
GB> As for the JDEE <-> Java interfacing issue, it's quite a difficult
GB> one. The approach I took was drawn from the Transmogrify way of
GB> doing it - all the logic was on the Java side and there was an
GB> interface to get basic
Hi!
Nick Sieger wrote:
[...]
> Maybe once the next generation of semantic is available we'll be able
> to do the entire refactoring engine in elisp, but until then, I think
> letting Java drive the control flow is OK as long as it can query
> Emacs for file/buffer info and let Emacs do the textual
> Yes but it's too trivial to implement as something separate from
> Nick's JUCI. It should be included in it.
I think this is a great idea! Did I miss the post about JUCI? I presume this
does some sort of reflected invocation scheme so that Emacs looks like a
Java class to the Java side and vice
Andy Piper writes:
> > Yes but it's too trivial to implement as something separate from
> > Nick's JUCI. It should be included in it.
>
> I think this is a great idea! Did I miss the post about JUCI? I presume this
> does some sort of reflected invocation scheme so that Emacs looks like a
>
> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes:
PK> Yep. I'm looking forward to seeing what Nick comes up with.
Here's the package documentation that I have so far. I plan to expand
more on the later sections. I'm also willing to package up what code
I have and send that along, but I d
11 matches
Mail list logo
