These are chat archives for ceylon/ceylon-ide-eclipse

16th
Apr 2016
Gavin King
@gavinking
Apr 16 2016 13:21
@bjansen the answer is that it’s almost impossible to integrate your new version of the refactoring because of the crappy circular dependencies between Java and Ceylon code in the Eclipse IDE
it’s really hard to convince the code to build
I just wasted hours on this, and I’m giving up now
Bastien Jansen
@bjansen
Apr 16 2016 13:22
rewrite the classes in Ceylon
xxInputPage and xxLinkedMode
I tried doing that too, and in the end refactorJ2C was returning a Refactoring, which was basically casted every time it's referenced
you can't use Ceylon declarations in imports, parameters or return types :(
kind of sucks
but rewriting the eclipse part in Ceylon might be a good idea if we end up abstracting all of the refactorings (using classes instead of interfaces)
Gavin King
@gavinking
Apr 16 2016 14:08
@bjansen Also, you broke it
Extract Function can impact multiple files now
a multi-file change is not a TextChange
Bastien Jansen
@bjansen
Apr 16 2016 14:09
TextChange is a new interface in ide-common
it can be whatever you want in Eclipse
Gavin King
@gavinking
Apr 16 2016 14:09
i know what it is
but it’s still not a multifile change
Bastien Jansen
@bjansen
Apr 16 2016 14:10
just make it a CompositeChange or whatever
Gavin King
@gavinking
Apr 16 2016 14:10
    void extractExpression(TextChange tfc, Tree.Term term,
        TextChange? change = null) {
That’s simply wrong, that signature
tfc and change have to be different sorts of things
and besides which you always pass a null change
And you have this signature
shared TextChange build() {
but build() sometimes returns a composite change
Bastien Jansen
@bjansen
Apr 16 2016 14:11
well it's still possible to wrap a composite change in a TextChange, isn't it?
Gavin King
@gavinking
Apr 16 2016 14:11
no
they are completely different kinds of things
they don’t have the same operations
Bastien Jansen
@bjansen
Apr 16 2016 14:12
ok, then we can add a second interface named CompositeChange
Bastien Jansen
@bjansen
Apr 16 2016 14:19
but it's not worth doing that change if we can't use the new version in Eclipse
Gavin King
@gavinking
Apr 16 2016 14:23
The other problem is that all the existing infrastructure assumes that the refactoring is an instance of org.eclipse.ltk.core.refactoring.Refactoring
which it’s not anymore
so there would be some adaptor needed
TBH it’s going to be pretty hard to make this work out
my preference remains to write refactorings as a collection of functions
this approach doesn’t seem to really have made anything very much simpler
i would take the existing working code
and factor out some stateless functions
with welldefined inputs and outputs
Bastien Jansen
@bjansen
Apr 16 2016 15:26
Well the existing eclipse impl would delegate to my class
But if you can come up with a better solution go ahead
I think we have basically two steps: select what to extract, and do the extraction
The second step is the new class
We just need a function fit the first step
For*
Bastien Jansen
@bjansen
Apr 16 2016 15:48
I mean you would keep the current EclipseEFR, but instead of satisfying the old interface, it'll delegate to the new class
The problems I had is that we can't use this class in Java signatures, because it'll generate build errors
Unless we rewrite the InputPage and LinkedMode in ceylon too
Also, it's calling setName after the refactoring is invoked, and the new class is immutable
Instantiated, not invoked sorry
Gavin King
@gavinking
Apr 16 2016 17:39
yeah, honestly, I’m not going to waste more time on this until @davidfestal comes up with a better modularization of the Eclipse IDE project, one where I can actually call a function written in Ceylon
Bastien Jansen
@bjansen
Apr 16 2016 18:55
I suppose there's still the possibility of restoring the old Java version of ExtractFunctionRefactoring, and in refactorInFile() just call my new Ceylon class
that wouldn't cause much bidirectional interop trouble
David Festal
@davidfestal
Apr 16 2016 19:29
@gavinking : we can use Ceylon functions from Java code, but have to respect strict limitations that come from the back end.
That's why such code should be encapsulated in the Java to Ceylon proxy objects, that are implemented in a distinct source directory. This "strange" structure is just a way to respect the constraints and limitations of the back end regarding bidirectional interop.
I cannot
David Festal
@davidfestal
Apr 16 2016 19:36
I cannot discuss this much now , sine I'm on my phone. I'll try to have a look next week. But yes fron tge beginning refactorings were interfaces for the exact purpose of being able to also extend the eclipse AbstractRefactoring class.