This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Re: Re: Time to encourage meaningful type parameter names? Discuss

2 replies
Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Type parameters are not just parameters like method parameters. The problem with projecting names onto type parameters, unlike method parameters, it that this departure from reality is *always* unwelcome (unlike coincidentally having no impact for method parameters). That is, you will always be wrong by virtue of them actually being universally quantified variables. You will never be right. There doesn't exist a case where projecting anything but "forall" onto a type parameter (in position of universal quantification) is sensible.

Always happy to prove any code incorrect, as a predictable consequence of continued subscription to these illusions.

On 11/18/2011 02:55 PM, Josh Suereth wrote:
>
> Guys, it seems The utility of this discussion has declined. Let's refrain from bloodying noses by continuing in the current vein.
>
> I'll throw something out there.
>
> Type parameters *are parameters * just like method parameters. If you think method parameters require a certain naming style, it is probably worthwhile to use this on type parameters.
>
> If a type parameter looks like a class/type, that's similar to a method parameter looking like a member / term. Notice the adjustments to the unofficial style guide for this.
>
> On Nov 17, 2011 11:39 PM, "Stefan Wagner" <hirnstrom [at] arcor [dot] de hirnstrom [at] arcor [dot] de (<mailto:hirnstrom [at] arcor [dot] de>)> wrote:
>
Am 17.11.2011 15:47, schrieb Matthew Pocock:
> Hi,

> Agreed. I have type parameters rendered in italic and type alases as
> italic+bold in intellij idea. I'm not a fan of Christmas-tree highlighting,
> but this seems to help.

+1 for Christmas-tree highlighting :) (let's abbr. it to CTH).

Maybe we should start a feature request for jline, for CTH in the REPL.


--
Tony Morris
http://tmorris.net/


Ken McDonald
Joined: 2011-02-13,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: Time to encourage meaningful type parameter names?


On Thursday, November 17, 2011 11:03:01 PM UTC-6, Tony Morris wrote:
Type parameters are not just parameters like method parameters. The problem with projecting names onto type parameters, unlike method parameters, it that this departure from reality is *always* unwelcome (unlike coincidentally having no impact for method parameters). That is, you will always be wrong by virtue of them actually being universally quantified variables. You will never be right. There doesn't exist a case where projecting anything but "forall" onto a type parameter (in position of universal quantification) is sensible.


Ohmigosh Tony, don't you ever get tired of being wrong? If I specify a type Tree[Root, Branches], are the meaningfulness of those names somehow obviated by the faint possibility that my type (in the context of my library) might be used for something else? Of course not. For that matter, there's a faint possibility that my code with variable names might find an application where those variable names are meaningless. Who the ^(^*)% cares? Software is design for what is real, not what is might be. If you design for everything that might be, you never complete anything.
I used to think of you as brilliant, but the more posts I see, the more I think of you as simply irrelevant.
Ken
Tony Morris
Joined: 2008-12-19,
User offline. Last seen 30 weeks 4 days ago.
Re: Re: Re: Time to encourage meaningful type parameter names?

You crack me up mate.

On Nov 20, 2011 11:29 AM, "Kenneth McDonald" <ykkenmcd [at] gmail [dot] com> wrote:


On Thursday, November 17, 2011 11:03:01 PM UTC-6, Tony Morris wrote:
Type parameters are not just parameters like method parameters. The problem with projecting names onto type parameters, unlike method parameters, it that this departure from reality is *always* unwelcome (unlike coincidentally having no impact for method parameters). That is, you will always be wrong by virtue of them actually being universally quantified variables. You will never be right. There doesn't exist a case where projecting anything but "forall" onto a type parameter (in position of universal quantification) is sensible.


Ohmigosh Tony, don't you ever get tired of being wrong? If I specify a type Tree[Root, Branches], are the meaningfulness of those names somehow obviated by the faint possibility that my type (in the context of my library) might be used for something else? Of course not. For that matter, there's a faint possibility that my code with variable names might find an application where those variable names are meaningless. Who the ^(^*)% cares? Software is design for what is real, not what is might be. If you design for everything that might be, you never complete anything.
I used to think of you as brilliant, but the more posts I see, the more I think of you as simply irrelevant.
Ken

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland