Wanted Refactorings?

Dear Michael,
How about add equality and hashcode methods? i believe that for classes the defaults on these are not as useful as they could be and generated the more useful default definitions is completely boilerplate.
Best wishes,
--greg

On Thu, Sep 22, 2011 at 10:38 AM, michael holzer <michi_holzer_news@gmx.at> wrote:

Hi everyone,

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

So far Mirko has implemented these refactorings:
- Rename
- Extract Local
- Inline Local
- Extract Method
- Organize Imports

What I've been working on so far:
- Curry Method (that is, splite parameter lists)
- Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
Int, a: Int))
- Replace constructor calls with calls to the apply-method of the
companion object, e.g:
 class Foo(bar: Int)
 class Using {
    val foo = new Foo(57)
 }

 becomes

 object Foo {
   def apply(bar: Int) = new Foo(bar)
 }
 class Foo(bar: Int)
 class Using {
    val foo = Foo(57)
 }


So, now to my question: which other refactorings would you like to see?

Thanks for any suggestions,
michael

[1] http://scala-refactoring.org/

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Dear Michael,
How about add equality and hashcode methods? i believe that for classes the defaults on these are not as useful as they could be and generated the more useful default definitions is completely boilerplate.
Best wishes,
--greg

On Thu, Sep 22, 2011 at 10:38 AM, michael holzer <michi_holzer_news@gmx.at> wrote:

Hi everyone,

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

So far Mirko has implemented these refactorings:
- Rename
- Extract Local
- Inline Local
- Extract Method
- Organize Imports

What I've been working on so far:
- Curry Method (that is, splite parameter lists)
- Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
Int, a: Int))
- Replace constructor calls with calls to the apply-method of the
companion object, e.g:
 class Foo(bar: Int)
 class Using {
    val foo = new Foo(57)
 }

 becomes

 object Foo {
   def apply(bar: Int) = new Foo(bar)
 }
 class Foo(bar: Int)
 class Using {
    val foo = Foo(57)
 }


So, now to my question: which other refactorings would you like to see?

Thanks for any suggestions,
michael

[1] http://scala-refactoring.org/

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Hi everyone,

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

So far Mirko has implemented these refactorings:
- Rename
- Extract Local
- Inline Local
- Extract Method
- Organize Imports

What I've been working on so far:
- Curry Method (that is, splite parameter lists)
- Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
Int, a: Int))
- Replace constructor calls with calls to the apply-method of the
companion object, e.g:
class Foo(bar: Int)
class Using {
val foo = new Foo(57)
}

becomes

object Foo {
def apply(bar: Int) = new Foo(bar)
}
class Foo(bar: Int)
class Using {
val foo = Foo(57)
}

So, now to my question: which other refactorings would you like to see?

Thanks for any suggestions,
michael

[1] http://scala-refactoring.org/

Hi Michael,

I would like to see rename work for identifiers in back ticks, e.g.
val `this strange identifier` = "foo"
=>
val `this even stranger identifier` = "foo"

Currently Eclipse won't let me do this …

Why would that be useful? Take a look at specs2: http://etorreborre.github.com/specs2/guide/org.specs2.guide.SpecStructur..., section "Acceptance specification"

Cheers,

Heiko

On Sep 22, 2011, at 7:38 PM, michael holzer wrote:

> Hi everyone,
>
> as my bachelor thesis I'm currently extending Mirko Stocker's
> refactoring library [1] to include more refactorings. The goal is also
> to include the new refactorings in the Scala IDE for Eclipse.
>
> So far Mirko has implemented these refactorings:
> - Rename
> - Extract Local
> - Inline Local
> - Extract Method
> - Organize Imports
>
> What I've been working on so far:
> - Curry Method (that is, splite parameter lists)
> - Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
> Int, a: Int))
> - Replace constructor calls with calls to the apply-method of the
> companion object, e.g:
> class Foo(bar: Int)
> class Using {
> val foo = new Foo(57)
> }
>
> becomes
>
> object Foo {
> def apply(bar: Int) = new Foo(bar)
> }
> class Foo(bar: Int)
> class Using {
> val foo = Foo(57)
> }
>
>
> So, now to my question: which other refactorings would you like to see?
>
> Thanks for any suggestions,
> michael
>
> [1] http://scala-refactoring.org/

Hi Michael,

I would like to see rename work for identifiers in back ticks, e.g.
val `this strange identifier` = "foo"
=>
val `this even stranger identifier` = "foo"

Currently Eclipse won't let me do this …

Why would that be useful? Take a look at specs2: http://etorreborre.github.com/specs2/guide/org.specs2.guide.SpecStructur..., section "Acceptance specification"

Cheers,

Heiko

On Sep 22, 2011, at 7:38 PM, michael holzer wrote:

> Hi everyone,
>
> as my bachelor thesis I'm currently extending Mirko Stocker's
> refactoring library [1] to include more refactorings. The goal is also
> to include the new refactorings in the Scala IDE for Eclipse.
>
> So far Mirko has implemented these refactorings:
> - Rename
> - Extract Local
> - Inline Local
> - Extract Method
> - Organize Imports
>
> What I've been working on so far:
> - Curry Method (that is, splite parameter lists)
> - Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
> Int, a: Int))
> - Replace constructor calls with calls to the apply-method of the
> companion object, e.g:
> class Foo(bar: Int)
> class Using {
> val foo = new Foo(57)
> }
>
> becomes
>
> object Foo {
> def apply(bar: Int) = new Foo(bar)
> }
> class Foo(bar: Int)
> class Using {
> val foo = Foo(57)
> }
>
>
> So, now to my question: which other refactorings would you like to see?
>
> Thanks for any suggestions,
> michael
>
> [1] http://scala-refactoring.org/

Hi Michael
One thing I find myself doing fairly often is creating a case class that simply ties several traits together.
With a two or three traits that each have half a dozen members, this gets verbose quite quickly.
It would save a fair amount of boilerplate typing if I could generate a case class with a constructor that had parameters from all of the traits members - possibly with defaults?
i.e.
trait A {  val i: Int  def j: Set[String]}
trait B {  val k: OtherCaseClass}
case class GeneratedAB(i: Int = 0, j: Set[String] = Set(), k: OtherCaseClass = OtherCaseClass()) extends A with B
Maybe this would make sense from the "New Class" wizard?  (Thinking in eclipse)
Thanks and good luck with the thesis,
Brian

On 22 September 2011 18:38, michael holzer <michi_holzer_news@gmx.at> wrote:

Hi everyone,

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

So far Mirko has implemented these refactorings:
- Rename
- Extract Local
- Inline Local
- Extract Method
- Organize Imports

What I've been working on so far:
- Curry Method (that is, splite parameter lists)
- Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
Int, a: Int))
- Replace constructor calls with calls to the apply-method of the
companion object, e.g:
 class Foo(bar: Int)
 class Using {
    val foo = new Foo(57)
 }

 becomes

 object Foo {
   def apply(bar: Int) = new Foo(bar)
 }
 class Foo(bar: Int)
 class Using {
    val foo = Foo(57)
 }


So, now to my question: which other refactorings would you like to see?

Thanks for any suggestions,
michael

[1] http://scala-refactoring.org/

Hi Michael
One thing I find myself doing fairly often is creating a case class that simply ties several traits together.
With a two or three traits that each have half a dozen members, this gets verbose quite quickly.
It would save a fair amount of boilerplate typing if I could generate a case class with a constructor that had parameters from all of the traits members - possibly with defaults?
i.e.
trait A {  val i: Int  def j: Set[String]}
trait B {  val k: OtherCaseClass}
case class GeneratedAB(i: Int = 0, j: Set[String] = Set(), k: OtherCaseClass = OtherCaseClass()) extends A with B
Maybe this would make sense from the "New Class" wizard?  (Thinking in eclipse)
Thanks and good luck with the thesis,
Brian

On 22 September 2011 18:38, michael holzer <michi_holzer_news@gmx.at> wrote:

Hi everyone,

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

So far Mirko has implemented these refactorings:
- Rename
- Extract Local
- Inline Local
- Extract Method
- Organize Imports

What I've been working on so far:
- Curry Method (that is, splite parameter lists)
- Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
Int, a: Int))
- Replace constructor calls with calls to the apply-method of the
companion object, e.g:
 class Foo(bar: Int)
 class Using {
    val foo = new Foo(57)
 }

 becomes

 object Foo {
   def apply(bar: Int) = new Foo(bar)
 }
 class Foo(bar: Int)
 class Using {
    val foo = Foo(57)
 }


So, now to my question: which other refactorings would you like to see?

Thanks for any suggestions,
michael

[1] http://scala-refactoring.org/

In the same vein.... How about an "introduce Product Trait" refactoring, which would add ProductN as a parent trait of the target class and generate all the required methods (including equals and hashcode as implemented via ScalaRuntime, the same as case classes)

On 22 September 2011 18:44, Meredith Gregory <lgreg.meredith@gmail.com> wrote:

Dear Michael,
How about add equality and hashcode methods? i believe that for classes the defaults on these are not as useful as they could be and generated the more useful default definitions is completely boilerplate.
Best wishes,
--greg

On Thu, Sep 22, 2011 at 10:38 AM, michael holzer <michi_holzer_news@gmx.at> wrote:

Hi everyone,

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

So far Mirko has implemented these refactorings:
- Rename
- Extract Local
- Inline Local
- Extract Method
- Organize Imports

What I've been working on so far:
- Curry Method (that is, splite parameter lists)
- Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
Int, a: Int))
- Replace constructor calls with calls to the apply-method of the
companion object, e.g:
 class Foo(bar: Int)
 class Using {
    val foo = new Foo(57)
 }

 becomes

 object Foo {
   def apply(bar: Int) = new Foo(bar)
 }
 class Foo(bar: Int)
 class Using {
    val foo = Foo(57)
 }


So, now to my question: which other refactorings would you like to see?

Thanks for any suggestions,
michael

[1] http://scala-refactoring.org/

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

In the same vein.... How about an "introduce Product Trait" refactoring, which would add ProductN as a parent trait of the target class and generate all the required methods (including equals and hashcode as implemented via ScalaRuntime, the same as case classes)

On 22 September 2011 18:44, Meredith Gregory <lgreg.meredith@gmail.com> wrote:

Dear Michael,
How about add equality and hashcode methods? i believe that for classes the defaults on these are not as useful as they could be and generated the more useful default definitions is completely boilerplate.
Best wishes,
--greg

On Thu, Sep 22, 2011 at 10:38 AM, michael holzer <michi_holzer_news@gmx.at> wrote:

Hi everyone,

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

So far Mirko has implemented these refactorings:
- Rename
- Extract Local
- Inline Local
- Extract Method
- Organize Imports

What I've been working on so far:
- Curry Method (that is, splite parameter lists)
- Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
Int, a: Int))
- Replace constructor calls with calls to the apply-method of the
companion object, e.g:
 class Foo(bar: Int)
 class Using {
    val foo = new Foo(57)
 }

 becomes

 object Foo {
   def apply(bar: Int) = new Foo(bar)
 }
 class Foo(bar: Int)
 class Using {
    val foo = Foo(57)
 }


So, now to my question: which other refactorings would you like to see?

Thanks for any suggestions,
michael

[1] http://scala-refactoring.org/

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Hi Heiko,

On 09/22/2011 08:26 PM, Heiko Seeberger wrote:
> Hi Michael,
>
> I would like to see rename work for identifiers in back ticks, e.g.
> val `this strange identifier` = "foo"
> =>
> val `this even stranger identifier` = "foo"
>
> Currently Eclipse won't let me do this …
I just tried this using the refactoring library directly. This way it
works, though there appear to be some formatting issues. So it seems to
be mainly an eclipse problem, maybe Mirko can say something more
detailed about it.

michael

Thanks for your suggestions! These definitely sound like good ideas, I
will try to implement them.

On the "introduce Product Trait" refactoring:
I assume it would work like this:

class Foo(a: Int, b: Int)

would be transformed to

class Foo(a: Int, b: Int) extends Product2[Int, Int] {
def _1 = a
def _2 = b
...
}

where "..." stands for everything else that's necessary (canEqual...)

michael

On 09/22/2011 09:40 PM, Kevin Wright wrote:
> In the same vein.... How about an "introduce Product Trait"
> refactoring, which would add ProductN as a parent trait of the target
> class and generate all the required methods (including equals and
> hashcode as implemented via ScalaRuntime, the same as case classes)
>
>
> On 22 September 2011 18:44, Meredith Gregory > wrote:
>
> Dear Michael,
>
> How about add equality and hashcode methods? i believe that for
> classes the defaults on these are not as useful as they could be
> and generated the more useful default definitions is completely
> boilerplate.
>
> Best wishes,
>
> --greg
>

Hi Brian,

I don't know how common this use case is, if there are many people who
would like this feature I'll give it a try. For know I'd rather start
with the other suggestions, but if there's time left I will also take a
look at this.
Thanks for your suggestion,
michael

On 09/22/2011 09:37 PM, Brian Smith wrote:
> Hi Michael
>
> One thing I find myself doing fairly often is creating a case class
> that simply ties several traits together.
>
> With a two or three traits that each have half a dozen members, this
> gets verbose quite quickly.
>
> It would save a fair amount of boilerplate typing if I could generate
> a case class with a constructor that had parameters from all of the
> traits members - possibly with defaults?
>
> i.e.
>
> trait A {
> val i: Int
> def j: Set[String]
> }
>
> trait B {
> val k: OtherCaseClass
> }
>
> case class GeneratedAB(i: Int = 0, j: Set[String] = Set(), k:
> OtherCaseClass = OtherCaseClass()) extends A with B
>
> Maybe this would make sense from the "New Class" wizard? (Thinking in
> eclipse)
>
> Thanks and good luck with the thesis,
>
> Brian

On Thu, Sep 22, 2011 at 10:38 AM, michael holzer <michi_holzer_news@gmx.at> wrote:

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

Talent borrows; genius steals. ;)
http://youtrack.jetbrains.com/issues?q=%23scala+subsystem%3Arefactoring+%23feature
-0xe1a

Michael,
Are these refactorings the ones that are implemented in the 2.0.0.beta10 release?  I ask because rename in beta10 has a number of issues.
-Clint
On Thu, Sep 22, 2011 at 1:38 PM, michael holzer <michi_holzer_news@gmx.at> wrote:

Hi everyone,

as my bachelor thesis I'm currently extending Mirko Stocker's
refactoring library [1] to include more refactorings. The goal is also
to include the new refactorings in the Scala IDE for Eclipse.

So far Mirko has implemented these refactorings:
- Rename
- Extract Local
- Inline Local
- Extract Method
- Organize Imports

What I've been working on so far:
- Curry Method (that is, splite parameter lists)
- Change Parameter Order (e.g. def foo(a: Int, b: Int) -> def foo(b:
Int, a: Int))
- Replace constructor calls with calls to the apply-method of the
companion object, e.g:
 class Foo(bar: Int)
 class Using {
    val foo = new Foo(57)
 }

 becomes

 object Foo {
   def apply(bar: Int) = new Foo(bar)
 }
 class Foo(bar: Int)
 class Using {
    val foo = Foo(57)
 }


So, now to my question: which other refactorings would you like to see?

Thanks for any suggestions,
michael

[1] http://scala-refactoring.org/

On 09/23/2011 08:22 PM, Clint Combs wrote:
> Are these refactorings the ones that are implemented in the
> 2.0.0.beta10 release? I ask because rename in beta10 has a number of
> issues.

yes, they are. As far as I know, Mirko is working on them.

michael

On 09/23/2011 07:09 PM, Alex Cruise wrote:
> On Thu, Sep 22, 2011 at 10:38 AM, michael holzer
> > wrote:
>
> as my bachelor thesis I'm currently extending Mirko Stocker's
> refactoring library [1] to include more refactorings. The goal is also
> to include the new refactorings in the Scala IDE for Eclipse.
>
>
> Talent borrows; genius steals. ;)
>
> http://youtrack.jetbrains.com/issues?q=%23scala+subsystem%3Arefactoring+...
>
> -0xe1a
oh, nice one, thanks :)

On 09/23/2011 07:09 PM, Alex Cruise wrote:
> On Thu, Sep 22, 2011 at 10:38 AM, michael holzer
> > wrote:
>
> as my bachelor thesis I'm currently extending Mirko Stocker's
> refactoring library [1] to include more refactorings. The goal is also
> to include the new refactorings in the Scala IDE for Eclipse.
>
>
> Talent borrows; genius steals. ;)
>
> http://youtrack.jetbrains.com/issues?q=%23scala+subsystem%3Arefactoring+...
>
> -0xe1a
oh, nice one, thanks :)

On 09/23/2011 08:22 PM, Clint Combs wrote:
> Are these refactorings the ones that are implemented in the
> 2.0.0.beta10 release? I ask because rename in beta10 has a number of
> issues.

yes, they are. As far as I know, Mirko is working on them.

michael

Hi,

On Friday 23 September 2011 15:24:00 michael holzer wrote:
> > I would like to see rename work for identifiers in back ticks, e.g.
> > val `this strange identifier` = "foo"
> > =>
> > val `this even stranger identifier` = "foo"
> >
> > Currently Eclipse won't let me do this …
>
> I just tried this using the refactoring library directly. This way it
> works, though there appear to be some formatting issues. So it seems to
> be mainly an eclipse problem, maybe Mirko can say something more
> detailed about it.

Yes that looks like a bug, I've created a ticket for it:

https://www.assembla.com/spaces/scala-refactoring/tickets/44-cannot-
rename-%60%60-identifiers-

Thanks for letting me know,

Mirko

On Friday 23 September 2011 20:40:58 michael holzer wrote:
> On 09/23/2011 08:22 PM, Clint Combs wrote:
> > Are these refactorings the ones that are implemented in the
> > 2.0.0.beta10 release? I ask because rename in beta10 has a number of
> > issues.

There are two unresolved issues I'm aware of:

https://www.assembla.com/spaces/scala-ide/tickets/1000622-rename-type-
refactor-does-not-catch-uses-of-the-name-in-type-parameters

https://www.assembla.com/spaces/scala-refactoring/tickets/44-cannot-
rename-%60%60-identifiers-

If you're seeing any other bugs, please create a ticket for them!

Thanks,

Mirko

On Friday 23 September 2011 20:40:58 michael holzer wrote:
> On 09/23/2011 08:22 PM, Clint Combs wrote:
> > Are these refactorings the ones that are implemented in the
> > 2.0.0.beta10 release? I ask because rename in beta10 has a number of
> > issues.

There are two unresolved issues I'm aware of:

https://www.assembla.com/spaces/scala-ide/tickets/1000622-rename-type-
refactor-does-not-catch-uses-of-the-name-in-type-parameters

https://www.assembla.com/spaces/scala-refactoring/tickets/44-cannot-
rename-%60%60-identifiers-

If you're seeing any other bugs, please create a ticket for them!

Thanks,

Mirko