way for scala-ide UI part implementations

[Jin Mingjian]

Hi, all:

according to Miles's suggestion, I post here one discussion about my recent thoughts about way for ui implementation. 

I suggest not to use the reflection tools or AspectJ to hook if the Eclipse platform and its sub-framework has provided the extension mechanism. This is true especially for UI part implementation. In the model side, the current scala-ide share some models with JDT. I think this kind of hooking is useful to reuse some model works. One reason is that, the model sides have not too much common points from generally speaking. So there are not much abstraction works of model in the platform. So, if we want to reuse somethings, we choose hooking. But this is not the case for UI side. The platform has a elegant UI abstraction hierarchy, SWT->JFace->Platform UI(workbench)->xdt. We don"t need to use the reflection tools or AspectJ to hook the JDT's counterpart. 

One example is that, I add one class ScalaHyperlinkDetector into the patch ticket #3251[1]. One reason for using ScalaHyperlinkDetector, because the ReflectionUtils+JDT HyperlinkDector lead to  a exception under 3.6. The advantages are obvious:

1. do not depend on the JDT Interfaces anymore;

2. do not need the reflection

3. allow ScalaHyperlinkDetector functionality to be on/off independently(that is, allow to be customized)

I am planning to use the JFace base to implement the annotation hover for implicit features and rework the current type hover implementation. How about all you think this? (avoiding the "ReflectionUtils" class in ui may be ultimate goal.) 

best regards,

Jin Mingjian

[1] http://www.assembla.com/spaces/scala-ide/tickets/3251-make-scala-ide-for-eclipse-workable-with-eclipse-3-6

[Miles Sabin]

On Mon, Jul 19, 2010 at 4:37 PM, Jin Mingjian <jin...@gmail.com> wrote:
> One example is that, I add one class ScalaHyperlinkDetector into the patch
> ticket #3251[1]. One reason for using ScalaHyperlinkDetector, because
> the ReflectionUtils+JDT HyperlinkDector lead to  a exception under 3.6.
> The advantages are obvious:
> 1. do not depend on the JDT Interfaces anymore;
> 2. do not need the reflection
> 3. allow ScalaHyperlinkDetector functionality to be on/off
> independently(that is, allow to be customized)

I take your point, but we get a lot of functionality from reusing the
JDT hovers. Do we lose anything with your replacement? Have you
checked the behaviour with references to Java entities in Scala source
and references to Scala entities in Java source?

Cheers,

Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[David Bernard]

I don't know exactly what scala-ide loose if ui no longer depends of
JDT, I'll list some pro (from my point of view) :
* I could have different syntax color rules that for Java
* I could set indentation of java 4 and scala 2 separetely
* I can keep auto-completion on for java code, I disable lot of
auto-completion, because Java auto-completion raise call to completion
engine (ScalaCodecompletionEngine and Templating for ~ every typed
caractere or 200ms => lot of useless recompilation of AST and
potential race condition (see Martin email) (analyse deduce but not
fully confirmed from my debug about completion/template support)
* when JDT weaving is not enabled then user will not have *.scala
parsed by java compiler with "strange" error
* display of method completion could follow scala syntax (not sure),
but will need to be reimplemted

But I also suppose that if scala-ide forgot to extend JavaEditor,...
lot of code will have to be duplicated (toggle comment,...) as some
feature check if it's a java editor,...

/davidB

[Jin Mingjian]

Yes, Miles. You hit the point. It is should be compatible with the current existed behavior. I will try to do some example to see how to solve this interoperability problem. If we share the model, I guess we still have the very more chance to contribute to the ui layer through extension.  

2010/7/20 Miles Sabin <mi...@milessabin.com>

[adrians]

You might want to consider using Object Teams. Andrew Eisenberg, who
worked on the new implementation of the Groovy-Eclipse IDE, wrote this
post detailing his views on extending the JDT to add Groovy support.
It would seem to be very relevant here.

http://contraptionsforprogramming.blogspot.com/2010/02/approaches-to-extending-jdt.html

Adrian


On Jul 19, 12:13 pm, Miles Sabin <mi...@milessabin.com> wrote:

[Miles Sabin]

On Thu, Jul 22, 2010 at 7:38 AM, adrians <nma...@gmail.com> wrote:
> You might want to consider using Object Teams. Andrew Eisenberg, who
> worked on the new implementation of the Groovy-Eclipse IDE, wrote this
> post detailing his views on extending the JDT to add Groovy support.
> It would seem to be very relevant here.
>
> http://contraptionsforprogramming.blogspot.com/2010/02/approaches-to-extending-jdt.html

We've been using AspectJ for quite some time now :-)

Or were you suggesting that Object Teams has benefits over AspectJ here?

Cheers,

Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com

[adrians]

Yes, that's what I meant, and what Andrew believes as well. He's the
author of JDT Weaving, and one of the authors of AJDT (which uses
AspectJ to extend the JDT similarly to the way you do, I believe) so I
would think his point of view is worth something. If you read through
the blog posting, you'll see what he meant.

Cheers



On Jul 22, 4:24 am, Miles Sabin <mi...@milessabin.com> wrote:

> On Thu, Jul 22, 2010 at 7:38 AM, adrians <nman...@gmail.com> wrote:
> > You might want to consider using Object Teams. Andrew Eisenberg, who
> > worked on the new implementation of the Groovy-Eclipse IDE, wrote this
> > post detailing his views on extending the JDT to add Groovy support.
> > It would seem to be very relevant here.
>

> >http://contraptionsforprogramming.blogspot.com/2010/02/approaches-to-...

[Miles Sabin]

On Fri, Jul 23, 2010 at 2:59 PM, adrians <nma...@gmail.com> wrote:
> Yes, that's what I meant, and what Andrew believes as well. He's the
> author of JDT Weaving, and one of the authors of AJDT (which uses
> AspectJ to extend the JDT similarly to the way you do, I believe) so I
> would think his point of view is worth something. If you read through
> the blog posting, you'll see what he meant.

I agree with Andrew that Object Teams would be interesting to explore,
but I also agree with him (unsurprisingly, seeing as we initiated the
project together at EclipseCon this year) that working with the JDT
team to provide better support for alternative JVM languages is the
way forward.

In the meantime, I don't see that Object Teams offers enough over
AspectJ to justify switching ... but feel free to try and persuade me
otherwise :-)

Cheers,

Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com

[Arioch]

В письме от Thu, 22 Jul 2010 12:24:20 +0400, Miles Sabin
<mi...@milessabin.com> сообщал:

> Or were you suggesting that Object Teams has benefits over AspectJ here?

Guess, it is like blind guessing now.
However, if e4 JDT would gain steam, then Scala-over-OT Weaving seems to
be possible (though frightening at same time) attempt.

If E4 JDT would have make large changes from current JDT + AJDT Weaving,
then probably those changes would lean either to Groove extending patchset
or OT design-changing patchset.

So potential benefits and gotchas of both approaches would be needed to be
tried in the real implementation.

Large projects, using Weaving, there are no much of them.

Scala, Groovy and OT themselves, who else Java's heir-rival?

Groovy prooved success using Groovy patchset.
OT obviously prooved success using OT patchset.

As far as i understand, Scala has success, using standart AJDT Weaving,
which is a subset of Groove patchset.

Seems to try real-world cons and pro's attempt to make two versions of
same large project is to be taken.
That maybe Groovy IDE reimplemented over OT patchset (and their
architecture).
That maybe Scala IDE reimplemented over OT patchset (and their
architecture).
That maybe OT IDE reimplemented over Groovy patchset. // But (according to
comments in Groove blog aforementioned) maybe their foundation is in
standard AJDT Weaving ? i did not understand quite. If so, then such
Groovy-port would be not architecture-changing but less-scale
compatibility fixing //

All those projects sounds overwhelmingly complex, gambling next to
impossible.

But with the hope that on early stages of such a project it would quickly
show either large benefits or large showstoppers, maybe it would finally
attempted, one of those three.

Other than that, without practical tests, how can consensus about e4 jdt
direction been fused ?
Either e4 jdt will result in large changes, appraised by everyone, with
all OT/Groovy/Scala IDEs been reimplemented over new common ground (then
attempt at Scala over OT would not be just waste of efforts but rather
early stages of Scala over e4jdt)
Or will not and Weaving would remain fragmented like it is now.

PS: personally i do not think this can be answered on Scala or Groovy or
OT forums.
This is more about e4 JDT fused initiative and would be decided within
there.
But before it gave fruits or fails, i think that interest would be stated
on languages' forums.

--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/