re: type inference being too hidden/silent

I disagree with this because the inferred type can change over time
due to changes in other code, and this would leave such comments incorrect
and misleading. (Less of a problem if absolutely all developers on a team use
the same IDE, but I would not want to count on that.)

> Date: Fri, 13 Mar 2009 10:43:08 -0700
> From: Raoul Duke
>
> hi,
>
> personally, i think the best feature would be for the IDE to
> automatically insert and update a comment which shows the type
> obtained from inference.
>
> sincerely.
>

> I disagree with this because the inferred type can change over time
> due to changes in other code, and this would leave such comments incorrect
> and misleading. (Less of a problem if absolutely all developers on a team use
> the same IDE, but I would not want to count on that.)

oh. dogged.

ok, then, inference sucks! :-) (i jest.)

sincerely.

On Fri, Mar 13, 2009 at 6:01 PM, David J. Biesack wrote:
> I disagree with this because the inferred type can change over time
> due to changes in other code, and this would leave such comments incorrect
> and misleading.

Putting the inferred types in comments isn't such a great idea.

But there's a better place to put them: in explicit type annotations ;-)

So I think what we really want are a pair of refactorings,

* Add type annotations from inferred types.

* Remove all inferable type annotations.

Cheers,

Miles

Maybe also "show/hide inferred types" - shows inferred types as if they were in the source, but highlighted to show that they've been synthesized and aren't embedded in the source.  Editing is allowed, but a type becomes embedded in the source on any edit.

On Fri, Mar 13, 2009 at 11:32 AM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Mar 13, 2009 at 6:01 PM, David J. Biesack <David.Biesack@sas.com> wrote:
> I disagree with this because the inferred type can change over time
> due to changes in other code, and this would leave such comments incorrect
> and misleading.

Putting the inferred types in comments isn't such a great idea.

But there's a better place to put them: in explicit type annotations ;-)

So I think what we really want are a pair of refactorings,

* Add type annotations from inferred types.

* Remove all inferable type annotations.

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

ooooh I cant ++++ that idea enough, it would be truly simple to
follow. (probably not to implement though :-> )

On Fri, Mar 13, 2009 at 7:40 PM, James Iry wrote:
> Maybe also "show/hide inferred types" - shows inferred types as if they were
> in the source, but highlighted to show that they've been synthesized and
> aren't embedded in the source.  Editing is allowed, but a type becomes
> embedded in the source on any edit.
>
> On Fri, Mar 13, 2009 at 11:32 AM, Miles Sabin wrote:
>>
>> On Fri, Mar 13, 2009 at 6:01 PM, David J. Biesack
>> wrote:
>> > I disagree with this because the inferred type can change over time
>> > due to changes in other code, and this would leave such comments
>> > incorrect
>> > and misleading.
>>
>> Putting the inferred types in comments isn't such a great idea.
>>
>> But there's a better place to put them: in explicit type annotations ;-)
>>
>> So I think what we really want are a pair of refactorings,
>>
>> * Add type annotations from inferred types.
>>
>> * Remove all inferable type annotations.
>>
>> Cheers,
>>
>>
>> Miles
>>
>> --
>> Miles Sabin
>> tel:    +44 (0)1273 720 779
>> mobile: +44 (0)7813 944 528
>> skype:  milessabin
>
>

On Fri, Mar 13, 2009 at 6:40 PM, James Iry wrote:
> Maybe also "show/hide inferred types" - shows inferred types as if they were
> in the source, but highlighted to show that they've been synthesized and
> aren't embedded in the source.  Editing is allowed, but a type becomes
> embedded in the source on any edit.

Not sure about this. It's a perfectly sensible idea in principle, but
I don't think it's idiomatic for Eclipse to show things as part of the
text which aren't actually there.

Something more idiomatic for Eclipse would be "folding" for inferrable
type annotations ... how about that?

Cheers,

Miles

On Fri, 2009-03-13 at 19:52 +0000, Miles Sabin wrote:
> On Fri, Mar 13, 2009 at 6:40 PM, James Iry wrote:
> > Maybe also "show/hide inferred types" - shows inferred types as if they were
> > in the source, but highlighted to show that they've been synthesized and
> > aren't embedded in the source. Editing is allowed, but a type becomes
> > embedded in the source on any edit.
>
> Not sure about this. It's a perfectly sensible idea in principle, but
> I don't think it's idiomatic for Eclipse to show things as part of the
> text which aren't actually there.

Eclipse idioms are heavily influenced by the needs of Java. Maybe it's
time to introduce a new one?

> Something more idiomatic for Eclipse would be "folding" for inferrable
> type annotations ... how about that?

This could work too, but seems like the sort of thing that needs
experimentation to see what works best.

Best,
Ismael

Miles,
On Fri, Mar 13, 2009 at 3:52 PM, Miles Sabin <miles@milessabin.com> wrote:

Not sure about this. It's a perfectly sensible idea in principle, but I don't think it's idiomatic for Eclipse to show things as part of the
text which aren't actually there.

They could be shown in a way that doesn't look like editable text. Maybe with little bubbles around them, like you can sometimes see for tags, or using a smaller font and a different baseline (like Google uses in GMail and elsewhere for tags). I agree with what you're saying, but I think it would be fairly easy to introduce a graphical convention that would avoid confusion.
Robert 

I agree that some Eclipse conventions may need to be re-considered in the light of certain Scala features.

The two scenarios in which I'd like to show/hide textual information (without affecting the source) are inferred types, implicit conversions, and implicit parameter passing. So, for example, the following line of code:

  val n = "3".toInt

could be toggled (hopefully with some keyboard shortcut) to become:

  val n*: Int* = *Predef.stringWrapper(*"3"*)*.toInt

Where the stuff between asterisks is grayed out or semi-transparent text to indicate that it is not part of my source code. It would update itself if my source code changes. This brings up a good question as to how to re-render this when the source changes. For example, if "3" is changed to 3. It could be confusing if text is appearing/disappearing from the page. Also, would this text be selectable or editable? I'm inclined to say not editable, but I'm not sure about selectable. This probably requires more thought.

Additional keyboard shortcuts would allow me to transform the source to:

  val n: Int = "3".toInt

or

  val n = Predef.stringWrapper("3").toInt

or the union of both. A similar argument applies to passing arguments into implicit parameters.

In addition, I'd love to see an option to "re-infer" a type. For example, if I have this code:

  val n: Int = "3".toInt

and I change it to look like:

  val n: Int = "3".toDouble  // error: type mismatch

a straightforward keyword shortcut should be able to "re-infer" the type of n and transform my source code into:

  val n: Double = "3".toDouble

(This may already be available in Eclipse/Java. I'm not familiar enough with it.)

These shortcuts should (if no text is selected) apply to either the line or the entire expression on which the text insertion caret resides. If text is selected, they should apply to the entire selected text.

2c,

--j

On Fri, Mar 13, 2009 at 2:11 PM, Robert Kosara <rkosara@gmail.com> wrote:

Miles,
On Fri, Mar 13, 2009 at 3:52 PM, Miles Sabin <miles@milessabin.com> wrote:

Not sure about this. It's a perfectly sensible idea in principle, but I don't think it's idiomatic for Eclipse to show things as part of the
text which aren't actually there.

They could be shown in a way that doesn't look like editable text. Maybe with little bubbles around them, like you can sometimes see for tags, or using a smaller font and a different baseline (like Google uses in GMail and elsewhere for tags). I agree with what you're saying, but I think it would be fairly easy to introduce a graphical convention that would avoid confusion.
Robert 

The two scenarios in which I'd like to show/hide textual information (without affecting the source) are inferred types, implicit conversions, and implicit parameter passing. So, for example, the following line of code:

  val n = "3".toInt

could be toggled (hopefully with some keyboard shortcut) to become:

  val n*: Int* = *Predef.stringWrapper(*"3"*)*.toInt

Where the stuff between asterisks is grayed out or semi-transparent text to indicate that it is not part of my source code. It would update itself if my source code changes. This brings up a good question as to how to re-render this when the source changes. For example, if "3" is changed to 3. It could be confusing if text is appearing/disappearing from the page. Also, would this text be selectable or editable? I'm inclined to say not editable, but I'm not sure about selectable. This probably requires more thought.

Ah-hah! To continue my own thought. Perhaps this grayed out or semi-transparent non-source textual information could be extremely transient. That is, it appears once toggled, but disappears as soon as you move the position of the text caret or try to edit source code. There could be small visual indicators to show where such information is available.

On second thought, perhaps this whole thing could be simulated with the source-code modifying version + undo.

2c,

--j

And by two scenarios I meant three.

--j "can't count"

On Fri, Mar 13, 2009 at 3:52 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

I agree that some Eclipse conventions may need to be re-considered in the light of certain Scala features.

The two scenarios in which I'd like to show/hide textual information (without affecting the source) are inferred types, implicit conversions, and implicit parameter passing. So, for example, the following line of code:

  val n = "3".toInt

could be toggled (hopefully with some keyboard shortcut) to become:

  val n*: Int* = *Predef.stringWrapper(*"3"*)*.toInt

Where the stuff between asterisks is grayed out or semi-transparent text to indicate that it is not part of my source code. It would update itself if my source code changes. This brings up a good question as to how to re-render this when the source changes. For example, if "3" is changed to 3. It could be confusing if text is appearing/disappearing from the page. Also, would this text be selectable or editable? I'm inclined to say not editable, but I'm not sure about selectable. This probably requires more thought.

Additional keyboard shortcuts would allow me to transform the source to:

  val n: Int = "3".toInt

or

  val n = Predef.stringWrapper("3").toInt

or the union of both. A similar argument applies to passing arguments into implicit parameters.

In addition, I'd love to see an option to "re-infer" a type. For example, if I have this code:

  val n: Int = "3".toInt

and I change it to look like:

  val n: Int = "3".toDouble  // error: type mismatch

a straightforward keyword shortcut should be able to "re-infer" the type of n and transform my source code into:

  val n: Double = "3".toDouble

(This may already be available in Eclipse/Java. I'm not familiar enough with it.)

These shortcuts should (if no text is selected) apply to either the line or the entire expression on which the text insertion caret resides. If text is selected, they should apply to the entire selected text.

2c,

--j

On Fri, Mar 13, 2009 at 2:11 PM, Robert Kosara <rkosara@gmail.com> wrote:

Miles,
On Fri, Mar 13, 2009 at 3:52 PM, Miles Sabin <miles@milessabin.com> wrote:

Not sure about this. It's a perfectly sensible idea in principle, but I don't think it's idiomatic for Eclipse to show things as part of the
text which aren't actually there.

They could be shown in a way that doesn't look like editable text. Maybe with little bubbles around them, like you can sometimes see for tags, or using a smaller font and a different baseline (like Google uses in GMail and elsewhere for tags). I agree with what you're saying, but I think it would be fairly easy to introduce a graphical convention that would avoid confusion.
Robert 

Instead of changing the text flow (which could destroy readability)
how about rendering this stuff as superscripts?

To make it fit it would probly have to both transparent and
overlapping, and I guess the opacity and level should follow the
cursor focus.

BR,
John

On Sat, Mar 14, 2009 at 12:01 AM, Jorge Ortiz wrote:
>
>> The two scenarios in which I'd like to show/hide textual information
>> (without affecting the source) are inferred types, implicit conversions, and
>> implicit parameter passing. So, for example, the following line of code:
>>
>>   val n = "3".toInt
>>
>> could be toggled (hopefully with some keyboard shortcut) to become:
>>
>>   val n*: Int* = *Predef.stringWrapper(*"3"*)*.toInt
>>
>> Where the stuff between asterisks is grayed out or semi-transparent text
>> to indicate that it is not part of my source code. It would update itself if
>> my source code changes. This brings up a good question as to how to
>> re-render this when the source changes. For example, if "3" is changed to 3.
>> It could be confusing if text is appearing/disappearing from the page. Also,
>> would this text be selectable or editable? I'm inclined to say not editable,
>> but I'm not sure about selectable. This probably requires more thought.
>
> Ah-hah! To continue my own thought. Perhaps this grayed out or
> semi-transparent non-source textual information could be extremely
> transient. That is, it appears once toggled, but disappears as soon as you
> move the position of the text caret or try to edit source code. There could
> be small visual indicators to show where such information is available.
>
> On second thought, perhaps this whole thing could be simulated with the
> source-code modifying version + undo.
>
> 2c,
>
> --j
>
>

Contributions welcome!

Sent from my iPhone

On Mar 13, 2009, at 7:01 PM, Jorge Ortiz wrote:

>
> The two scenarios in which I'd like to show/hide textual information
> (without affecting the source) are inferred types, implicit
> conversions, and implicit parameter passing. So, for example, the
> following line of code:
>
> val n = "3".toInt
>
> could be toggled (hopefully with some keyboard shortcut) to become:
>
> val n*: Int* = *Predef.stringWrapper(*"3"*)*.toInt
>
> Where the stuff between asterisks is grayed out or semi-transparent
> text to indicate that it is not part of my source code. It would
> update itself if my source code changes. This brings up a good
> question as to how to re-render this when the source changes. For
> example, if "3" is changed to 3. It could be confusing if text is
> appearing/disappearing from the page. Also, would this text be
> selectable or editable? I'm inclined to say not editable, but I'm
> not sure about selectable. This probably requires more thought.
>
> Ah-hah! To continue my own thought. Perhaps this grayed out or semi-
> transparent non-source textual information could be extremely
> transient. That is, it appears once toggled, but disappears as soon
> as you move the position of the text caret or try to edit source
> code. There could be small visual indicators to show where such
> information is available.
>
> On second thought, perhaps this whole thing could be simulated with
> the source-code modifying version + undo.
>
> 2c,
>
> --j
>

On Fri, Mar 13, 2009 at 6:52 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

I agree that some Eclipse conventions may need to be re-considered in the light of certain Scala features.

The two scenarios in which I'd like to show/hide textual information (without affecting the source) are inferred types, implicit conversions, and implicit parameter passing. So, for example, the following line of code:

  val n = "3".toInt

could be toggled (hopefully with some keyboard shortcut) to become:

  val n*: Int* = *Predef.stringWrapper(*"3"*)*.toInt

I dunno.  Admittedly, I'm used to the Eclipse way of doing things, but I think the rollover popups that we already have are the right direction to go in.  Those already include inferred return types; I can see eventually adding other inferences.  But I think that having the pseudo-code in-line with the real code would be far more confusing, and I honestly don't see enough value in having shortcuts to formalize those inferences into the code -- it just doesn't seem like something that would be more than occasionally useful...

On Fri, 2009-03-13 at 22:25 -0400, Justin du coeur wrote:
> I dunno. Admittedly, I'm used to the Eclipse way of doing things, but
> I think the rollover popups that we already have are the right
> direction to go in.

Rollover pop-ups and the mechanism being proposed here serve different
needs. The former is useful in codebases that one knows well where one
might want to check the occasional type while the latter is useful when
trying to understand a codebase that is less familiar (there is some
overlap too, of course).

It seems to me that activating all the type annotations in a block of
code would be much more productive than manually activating a large
number of tooltips individually.

Best,
Ismael

On Sat, Mar 14, 2009 at 3:00 AM, Ismael Juma wrote:
> On Fri, 2009-03-13 at 22:25 -0400, Justin du coeur wrote:
>> I dunno.  Admittedly, I'm used to the Eclipse way of doing things, but
>> I think the rollover popups that we already have are the right
>> direction to go in.
>
> Rollover pop-ups and the mechanism being proposed here serve different
> needs. The former is useful in codebases that one knows well where one
> might want to check the occasional type while the latter is useful when
> trying to understand a codebase that is less familiar (there is some
> overlap too, of course).
>
> It seems to me that activating all the type annotations in a block of
> code would be much more productive than manually activating a large
> number of tooltips individually.

I think for this scenario (reviewing/exploring an unfamiliar codebase)
you're absolutely right.

I'm less convinced that it would be desirable for normal everyday
work, because I have this old-fashioned idea that it's important that
what I can see in my editor exactly matches what's in the source files
on disc and checked into the VCS.

But what the heck, let a hundred flowers bloom ... these all seem like
plausible mechanisms, and it'd be good to be able to experiment with
them and see what works and what doesn't.

Cheers,

Miles

On Sat, 2009-03-14 at 15:20 +0000, Miles Sabin wrote:
> I think for this scenario (reviewing/exploring an unfamiliar codebase)
> you're absolutely right.
>
> I'm less convinced that it would be desirable for normal everyday
> work, because I have this old-fashioned idea that it's important that
> what I can see in my editor exactly matches what's in the source files
> on disc and checked into the VCS.

Yes, I agree.

> But what the heck, let a hundred flowers bloom ... these all seem like
> plausible mechanisms, and it'd be good to be able to experiment with
> them and see what works and what doesn't.

Indeed.

Ismael

Miles Sabin wrote:
> On Sat, Mar 14, 2009 at 3:00 AM, Ismael Juma wrote:
>
>> On Fri, 2009-03-13 at 22:25 -0400, Justin du coeur wrote:
>>
>>> I dunno. Admittedly, I'm used to the Eclipse way of doing things, but
>>> I think the rollover popups that we already have are the right
>>> direction to go in.
>>>
>> Rollover pop-ups and the mechanism being proposed here serve different
>> needs. The former is useful in codebases that one knows well where one
>> might want to check the occasional type while the latter is useful when
>> trying to understand a codebase that is less familiar (there is some
>> overlap too, of course).
>>
>> It seems to me that activating all the type annotations in a block of
>> code would be much more productive than manually activating a large
>> number of tooltips individually.
>>
>
> I think for this scenario (reviewing/exploring an unfamiliar codebase)
> you're absolutely right.
>
> I'm less convinced that it would be desirable for normal everyday
> work, because I have this old-fashioned idea that it's important that
> what I can see in my editor exactly matches what's in the source files
> on disc and checked into the VCS.
>
> But what the heck, let a hundred flowers bloom ... these all seem like
> plausible mechanisms, and it'd be good to be able to experiment with
> them and see what works and what doesn't.
>
>
When Eclipse puts the little +'s for folding in the margin, or line
numbers, that isn't in your source code. Nor is the font style and
coloring changes of syntax highlighting. It's only a small step for the
same to be true of some bits of text shown inline with the source. The
important thing, it seems to me, is that the stylization very clearly
distinguish it from the text that IS in the in your source, in a way
that is immediately obvious.

Eric

On Sat, Mar 14, 2009 at 4:50 PM, Eric Schwarzenbach
wrote:
> When Eclipse puts the little +'s for folding in the margin, or line
> numbers, that isn't in your source code. Nor is the font style and
> coloring changes of syntax highlighting.  It's only a small step for the
> same to be true of some bits of text shown inline with the source. The
> important thing, it seems to me, is that the stylization very clearly
> distinguish it from the text that IS in the in your source, in a way
> that is immediately obvious.

To be honest, I think that's a very _big_ step in changing the way
that information is presented ... crucial difference here is out of
line vs. inline.

But as I said, let a hundred flowers bloom, YMMV, etc. etc. ...

Cheers,

Miles

Miles Sabin wrote:
> On Sat, Mar 14, 2009 at 4:50 PM, Eric Schwarzenbach
> wrote:
>
>> When Eclipse puts the little +'s for folding in the margin, or line
>> numbers, that isn't in your source code. Nor is the font style and
>> coloring changes of syntax highlighting. It's only a small step for the
>> same to be true of some bits of text shown inline with the source. The
>> important thing, it seems to me, is that the stylization very clearly
>> distinguish it from the text that IS in the in your source, in a way
>> that is immediately obvious.
>>
>
> To be honest, I think that's a very _big_ step in changing the way
> that information is presented ... crucial difference here is out of
> line vs. inline.
>
I agree. As someone pointed out it would not be idiomatic to Eclipse,
essentially it would require a new idiom. For one thing, such text would
have to be un-editable. It ought to employ some entirely different way
of distinguishing itself visually, for example being in slightly smaller
text, inside a box with a different background color (and then there's
the feasibility issue within Eclipse). The cost of such a step would be
more justifiable if there were other useful applications for showing
implied syntax inline.

Eric

I think a simple idiomatic way is to have a tabbed edit pane, like
wsdl or xml or manifests etc. Btw I mean simple in terms of concept
only. Edit vs fully expanded view. If developers want to see side by
side then open another editor and drag the window to another doc.

This I hope would also be realistic to develop in terms of use rs/age
vs cost and complexity of development.

On Sat, Mar 14, 2009 at 7:22 PM, Eric Schwarzenbach
wrote:
> Miles Sabin wrote:
>> On Sat, Mar 14, 2009 at 4:50 PM, Eric Schwarzenbach
>> wrote:
>>
>>> When Eclipse puts the little +'s for folding in the margin, or line
>>> numbers, that isn't in your source code. Nor is the font style and
>>> coloring changes of syntax highlighting.  It's only a small step for the
>>> same to be true of some bits of text shown inline with the source. The
>>> important thing, it seems to me, is that the stylization very clearly
>>> distinguish it from the text that IS in the in your source, in a way
>>> that is immediately obvious.
>>>
>>
>> To be honest, I think that's a very _big_ step in changing the way
>> that information is presented ... crucial difference here is out of
>> line vs. inline.
>>
> I agree. As someone pointed out it would not be idiomatic to Eclipse,
> essentially it would require a new idiom. For one thing, such text would
> have to be un-editable. It ought to employ some entirely different way
> of distinguishing itself visually, for example being in slightly smaller
> text, inside a box with a different background color (and then there's
> the feasibility issue within Eclipse). The cost of such a step would be
> more justifiable if there were other useful applications for showing
> implied syntax inline.
>
> Eric
>

Ho wabout doing the same for inferred calls to those evil implicit defs for which everybody hates Scala, if he doesn't love Scala for other reasons. ;-)
Szymon 

On Fri, Mar 13, 2009 at 8:52 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Mar 13, 2009 at 6:40 PM, James Iry <jamesiry@gmail.com> wrote:
> Maybe also "show/hide inferred types" - shows inferred types as if they were
> in the source, but highlighted to show that they've been synthesized and
> aren't embedded in the source.  Editing is allowed, but a type becomes
> embedded in the source on any edit.

Not sure about this. It's a perfectly sensible idea in principle, but
I don't think it's idiomatic for Eclipse to show things as part of the
text which aren't actually there.

Something more idiomatic for Eclipse would be "folding" for inferrable
type annotations ... how about that?

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

--
ʎɐqǝ uo pɹɐoqʎǝʞ ɐ ʎnq ı ǝɯıʇ ʇsɐן ǝɥʇ sı sıɥʇ