[scala-ide-dev] [GSOC]details of my features proposal

[Jin Mingjian]

Hi, all,

I have created one wiki page about those features to be implemented in this years' GSOC here[1]. The three features are pinned at the desktop, which should be completed in this summer. If all goes well, I guess there will be room to contribute more  features. 

The current proposal in [1] is about the features you will see, not the implementation of those features. And those features are based on my understanding. I guess it is very possible to miss somethings in this propsal. If you have some suggestions, please tell me:) 

Best regards,

Jin Mingjian

[1] http://www.assembla.com/wiki/show/scala-ide/Google_Summer_of_Code

[Miles Sabin]

On Wed, May 19, 2010 at 2:27 AM, Jin Mingjian <jin...@gmail.com> wrote:
> I have created one wiki page about those features to be implemented in this
> years' GSOC here[1]. The three features are pinned at the desktop, which
> should be completed in this summer. If all goes well, I guess there will be
> room to contribute more  features.
> The current proposal in [1] is about the features you will see, not the
> implementation of those features. And those features are based on my
> understanding. I guess it is very possible to miss somethings in this
> propsal. If you have some suggestions, please tell me:)

This looks like really great stuff :-)

Cheers,


Miles

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

[Matt Russell]

This looks awesome. I think this is one of those cases where the
viability of a language feature is closely connected to tool support.
A lot of the sharp edges of implicits could be mitigated by
integration with the IDE.

"we can reuse yellow squiggly underline which has been used as the
"Problem" indicator if we do not want to distinguish the differences
of "Implicits" and current "Problem""

Personally, I think it would be better to avoid conflating information-
only annotations and error/warning annotations.

"A. "expanding inferred types" is considered to be done in the way
of code completion when : activation with id:."

I couldn't quite follow what you meant here.

-- Matt

[Jin Mingjian]

Hi, Matt, thanks for sugguestions:)  I really forget something as your reminding. The meaning of  "expanding inferred types", as my orginal thought, may be like the follow:

val a=1 

    => val a:Int = 1

def getString = "abc"

    => def getString:String = "abc"

And yes, if the RHS of = has not been typed, the engine can not infer out the type of LHS of =.  This can be done in Ctrl+1 way as well.  This feature could be considered as the enhancement to the code completion. I will adjust this features to a sub-task of code completion to deep in further(the current code completion seemly not supported at anywhere, see bug[1]).

for " which type of annotation", I agree with you personally. One thing that I am not sure, is whether the people like to use the yellow squiggly underline as the indicator for the quick-fixing things habitually. It may be better to choose one default after the prototype of implementation being out:) Any others who has some ideas about this can drop comments.

one note: this proposal has not been checked by Miles before its posted here for time reason. So, if there are some mistakes, all mistakes belongs to me definitely:)

Thanks again, Matt!

[1] https://www.assembla.com/spaces/scala-ide/tickets/2957-completion-is-not-working-at-some-positions

2010/5/19 Matt Russell <mattru...@googlemail.com>

[Jin Mingjian]

I remember one non-assignment case, like this:

          val a = "a"

 val c = (a:String) + "x"

 println(c)

here, a is expanded to a:String(expression of Ids is also supported by this style usage). Although it seem not much necessary, more is better than less:) And I find, from this viewpoint, feature#2 and feature#3 can share something. Good:)

2010/5/19 Matt Russell <mattru...@googlemail.com>

[Ian Clarke]

On Wed, May 19, 2010 at 2:34 PM, Matt Russell <mattru...@googlemail.com> wrote:

This looks awesome. I think this is one of those cases where the
viability of a language feature is closely connected to tool support.
A lot of the sharp edges of implicits could be mitigated by
integration with the IDE.

 "we can reuse yellow squiggly underline which has been used as the
"Problem" indicator if we do not want to distinguish the differences
of "Implicits" and current "Problem""

Personally, I think it would be better to avoid conflating information-
only annotations and error/warning annotations.

Agreed.  I associate squiggly underlines  (of whatever color) with a warning, or error.  I don't think we should use them to indicate something that isn't problematic in some way.

 

Ian.

--
Ian Clarke
CEO, SenseArray
Email: i...@sensearray.com
Ph: +1 512 422 3588

[Jin Mingjian]

got it:) I will speedup coding in this week.

2010/5/31 Ian Clarke <i...@sensearray.com>