Quantcast

Scala-Wicket Help and Advice

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Scala-Wicket Help and Advice

richard emberson
Dev Wicketers,

What: I have ported Wicket to Scala
     A couple of months ago I took a 1.5 snapshot and ported to Scala.
     This encompasses all of the source and test code. As successive 1.5
     snapshots were released, I ported those differences to my Scala
     version. I am current with 1.5 M3.

     The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
     counting all the println statements I put into the Scala code
     for debugging). I used cloc (http://cloc.sourceforge.net/) to
     count lines of code.

     I have also replaced all of the Java collection classes with
     Scala collection classes (though a small number of Java collection
     classes remain that did not have comparable Scala implementations).

     I have changed many method return types from the Java returning
     some "object" or "null" to Scala returning "Some(object)" or "None"
     (using the Scala Option[return-type] construct) - trying to
     eliminate nulls.

     Lastly, I pushed the IModel[T] typing down to the Component class
     making get/set DefaultModel and get/set DefaultModelObject strong
     typed.  This included using Scala companion object apply methods
     which eliminated having to explicitly declare type parameters in
     most end-user code (I had read that one of the objections to
     pushing strong typing down to the Component class in Wicket was
     that there were "too many notes", end-user code was too verbose).

     It can not interoperate with Java Wicket because Scala compiles to
     JVM class files and so all of the classes in Java Wicket also
     appear in Scala-Wicket.

     I have an "internal" name for my Scala port of Wicket which
     acknowledges its Wicket heritage as well as advertises its
     enterprise level capabilities. For external communications,
     I am currently simply call it Scala-Wicket.

Why: Scala is a better Java
     I was introduced to Scala 9 months ago and quickly determined that
     it was a better Java (at least IMO). For Scala to succeed it
     requires more programmers to use it. Many on the Scala mailing
     lists were from a functional background and seemed not to recognize
     that Haskell and Lisp are not blindingly successful but, rather,
     niche languages and that the heavy selling of Scala's function and
     typing capabilities might turn off Java programmers.

     Scala struck me in many ways as a strong-typed JavaScript, at
     least, much of the code did not have to have type declarations
     because the compiler could infer types in many cases. In addition,
     a whole lot of the Java boil-plate code was not needed. As such,
     it could be sold as simply a better Java; a more-to-the-point
     object oriented language with functional programming in-the-small.

     To get more Java programmers to try Scala I looked for a
     significant Java application with a strong support and user
     community that I could port to Scala. I ended up with Wicket.
     Wicket is an enterprise level web framework (unlike existing
     Scale web frameworks which place restrictions on enterprise IT
     organizations, e.g., by requiring sticky sessions).  It is well
     documented. And, as it turned out, very, very importantly it had
     a large number of unit tests (the unit tests saved my butt,
     without them I would never had succeeded in getting a port that
     worked).

     No, Really, Why:
         I like Scala and I took the time to learn it. Right now about
         20% of programmers use Java while only some 0.4% use Scala.
         I did not want my effort of learning Scala to be wasted so my
         solution is to increase the number of Scala programmers. Where
         to get them? Again, my solution is from the existing horde of
         Java programmers.

Plans: Release, Evolve and Proselytize
     I would like to release Scala-Wicket.
     I do not know if Apache hosts anything other than Java code.
     Growing a community is important.

     Still Todo:
         Comments: All of the existing class and inline comments are
             still Java related.  This would have to be a long, on-going
             task to edit the comments so they reflect the code's
             Scala usage.
         Package path: The code still uses the "org.apache.wicket"
             package path and this must be changed - unless this became
             an Apache project.
         Author: I have quite literally looked at and touched every line
             of code but I have not yet felt comfortable with adding
             myself as an author since, well, many changes were
             syntactic and not semantic.
         Refactor with Traits: Currently the port uses Scala traits like
             Java interfaces but it should be possible to factor the
             common code out into the traits. This would result in many
             of the interfaces, the "I" files, such as IModel.scala,
             going away.
         Some general refactoring:
             As an example, consider factoring out the IModel[T] from
             Component. Half the time a user wants a Component with
             no model, so, if there was a HasModel trait:
                 class Model[T](var value: T) {
                     def getObject: T = value
                     def setObject(value: T): Unit = this.value = value
                 }
                 trait HasModel[T] {
                   var model: Model[T]
                   def getDefaultModel: IModel[T] = model
                   def setDefaultModel(model: IModel[T]): this.type = {
                     ....
                     this
                   }
                   def getDefaultModelObject: Option[T] = {
                     ....
                   }
                   def setDefaultModelObject(obj: T): this.type = {
                     ....
                     this
                   }
                 }
             The Component hierarchy would have no model support.
             The user could add model support when needed:
                 val form = new Form("hi")
                   with HasModel[Int] { var model = new Model(42) }
             Just an Idea.
         STM: There are a number of Scala STM projects and I do not know
             if it is useful to add STM capabilities to Scala-Wicket.
         RBAC: I've written a Scala implementation of the NIST RBAC
             recommended standard and might consider adding it.
         Logging: Adding a Scala-based logging framework to aid user
             debugging.
         Monitoring and stats: In the last couple of years many web
             sites have added monitoring and statistics gathering
             capabilities (e.g., who clicks what, where, how long, on
             what page does the visitor exit the web site, etc.) in
             order to know how the web site is being used and then
             improve the web site.
         Significant Memory Usage Reduction: I've an idea that would
             significantly decrease the memory usage of Scala-Wicket and
             I plan to do a test implementation.
         Replace Java features: There are still some Java-isms that can
             be replaced with Scala equivalents.
         Port additional Java Wicket libraries to Scala.
         Enable multiple instances of a unit tests to be run at once.
         More: ????????????

     I want to avoid using some of the WTF features of Scala (when a
         Java programmer looks at the code and says "WTF") in order to
         ease and accelerate acceptance by Java programmers; as
         examples, implicits can make code hard to understand and
         advanced Scala type usages, as James Gosling said, "makes one's
         head spin".


Help and Advice: How should Scala-Wicket be extended and released

     Scala-Wicket is a port and evolution of Wicket, not a ground-up
         re-write. Given that, what would you do differently in Wicket
         now that there are years of experience using it?

     How best to get a hosting site, release the code and build a
         community?

     Are there any mechanism to help fund such an open-source project?

This is not meant to be a general announcement but rather a means
for me to get some initial advice as to how to proceed.

Any help is appreciated.

Richard Emberson


--
Quis custodiet ipsos custodes
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Cemal Bayramoglu
Richard,

This is an interesting idea that several people have discussed over
the last few years. I congratulate you on having taken it so far and
look forward to seeing your implementation.

As long as it can evolve in a way that can not do any harm to Wicket
(ie the quality is exceptional, the community accepts and supports it
etc), jWeekend is also interested in supporting this project. Let me
know if you 'd like to discuss further.

In the meantime, you may also like to take a look at unfiltered [1],
another relatively new Scala project, developed by some pretty smart
guys, one of which was a big Wicket fan too (Nathan created
databinder) which you may be able to gainfully integrate.

Regards - Cemal
jWeekend
Training, Consulting, Development
http://jWeekend.com

[1] https://github.com/n8han/unfiltered

On 4 January 2011 23:15, richard emberson <[hidden email]> wrote:

> Dev Wicketers,
>
> What: I have ported Wicket to Scala
>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
>    This encompasses all of the source and test code. As successive 1.5
>    snapshots were released, I ported those differences to my Scala
>    version. I am current with 1.5 M3.
>
>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>    counting all the println statements I put into the Scala code
>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
>    count lines of code.
>
>    I have also replaced all of the Java collection classes with
>    Scala collection classes (though a small number of Java collection
>    classes remain that did not have comparable Scala implementations).
>
>    I have changed many method return types from the Java returning
>    some "object" or "null" to Scala returning "Some(object)" or "None"
>    (using the Scala Option[return-type] construct) - trying to
>    eliminate nulls.
>
>    Lastly, I pushed the IModel[T] typing down to the Component class
>    making get/set DefaultModel and get/set DefaultModelObject strong
>    typed.  This included using Scala companion object apply methods
>    which eliminated having to explicitly declare type parameters in
>    most end-user code (I had read that one of the objections to
>    pushing strong typing down to the Component class in Wicket was
>    that there were "too many notes", end-user code was too verbose).
>
>    It can not interoperate with Java Wicket because Scala compiles to
>    JVM class files and so all of the classes in Java Wicket also
>    appear in Scala-Wicket.
>
>    I have an "internal" name for my Scala port of Wicket which
>    acknowledges its Wicket heritage as well as advertises its
>    enterprise level capabilities. For external communications,
>    I am currently simply call it Scala-Wicket.
>
> Why: Scala is a better Java
>    I was introduced to Scala 9 months ago and quickly determined that
>    it was a better Java (at least IMO). For Scala to succeed it
>    requires more programmers to use it. Many on the Scala mailing
>    lists were from a functional background and seemed not to recognize
>    that Haskell and Lisp are not blindingly successful but, rather,
>    niche languages and that the heavy selling of Scala's function and
>    typing capabilities might turn off Java programmers.
>
>    Scala struck me in many ways as a strong-typed JavaScript, at
>    least, much of the code did not have to have type declarations
>    because the compiler could infer types in many cases. In addition,
>    a whole lot of the Java boil-plate code was not needed. As such,
>    it could be sold as simply a better Java; a more-to-the-point
>    object oriented language with functional programming in-the-small.
>
>    To get more Java programmers to try Scala I looked for a
>    significant Java application with a strong support and user
>    community that I could port to Scala. I ended up with Wicket.
>    Wicket is an enterprise level web framework (unlike existing
>    Scale web frameworks which place restrictions on enterprise IT
>    organizations, e.g., by requiring sticky sessions).  It is well
>    documented. And, as it turned out, very, very importantly it had
>    a large number of unit tests (the unit tests saved my butt,
>    without them I would never had succeeded in getting a port that
>    worked).
>
>    No, Really, Why:
>        I like Scala and I took the time to learn it. Right now about
>        20% of programmers use Java while only some 0.4% use Scala.
>        I did not want my effort of learning Scala to be wasted so my
>        solution is to increase the number of Scala programmers. Where
>        to get them? Again, my solution is from the existing horde of
>        Java programmers.
>
> Plans: Release, Evolve and Proselytize
>    I would like to release Scala-Wicket.
>    I do not know if Apache hosts anything other than Java code.
>    Growing a community is important.
>
>    Still Todo:
>        Comments: All of the existing class and inline comments are
>            still Java related.  This would have to be a long, on-going
>            task to edit the comments so they reflect the code's
>            Scala usage.
>        Package path: The code still uses the "org.apache.wicket"
>            package path and this must be changed - unless this became
>            an Apache project.
>        Author: I have quite literally looked at and touched every line
>            of code but I have not yet felt comfortable with adding
>            myself as an author since, well, many changes were
>            syntactic and not semantic.
>        Refactor with Traits: Currently the port uses Scala traits like
>            Java interfaces but it should be possible to factor the
>            common code out into the traits. This would result in many
>            of the interfaces, the "I" files, such as IModel.scala,
>            going away.
>        Some general refactoring:
>            As an example, consider factoring out the IModel[T] from
>            Component. Half the time a user wants a Component with
>            no model, so, if there was a HasModel trait:
>                class Model[T](var value: T) {
>                    def getObject: T = value
>                    def setObject(value: T): Unit = this.value = value
>                }
>                trait HasModel[T] {
>                  var model: Model[T]
>                  def getDefaultModel: IModel[T] = model
>                  def setDefaultModel(model: IModel[T]): this.type = {
>                    ....
>                    this
>                  }
>                  def getDefaultModelObject: Option[T] = {
>                    ....
>                  }
>                  def setDefaultModelObject(obj: T): this.type = {
>                    ....
>                    this
>                  }
>                }
>            The Component hierarchy would have no model support.
>            The user could add model support when needed:
>                val form = new Form("hi")
>                  with HasModel[Int] { var model = new Model(42) }
>            Just an Idea.
>        STM: There are a number of Scala STM projects and I do not know
>            if it is useful to add STM capabilities to Scala-Wicket.
>        RBAC: I've written a Scala implementation of the NIST RBAC
>            recommended standard and might consider adding it.
>        Logging: Adding a Scala-based logging framework to aid user
>            debugging.
>        Monitoring and stats: In the last couple of years many web
>            sites have added monitoring and statistics gathering
>            capabilities (e.g., who clicks what, where, how long, on
>            what page does the visitor exit the web site, etc.) in
>            order to know how the web site is being used and then
>            improve the web site.
>        Significant Memory Usage Reduction: I've an idea that would
>            significantly decrease the memory usage of Scala-Wicket and
>            I plan to do a test implementation.
>        Replace Java features: There are still some Java-isms that can
>            be replaced with Scala equivalents.
>        Port additional Java Wicket libraries to Scala.
>        Enable multiple instances of a unit tests to be run at once.
>        More: ????????????
>
>    I want to avoid using some of the WTF features of Scala (when a
>        Java programmer looks at the code and says "WTF") in order to
>        ease and accelerate acceptance by Java programmers; as
>        examples, implicits can make code hard to understand and
>        advanced Scala type usages, as James Gosling said, "makes one's
>        head spin".
>
>
> Help and Advice: How should Scala-Wicket be extended and released
>
>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
>        re-write. Given that, what would you do differently in Wicket
>        now that there are years of experience using it?
>
>    How best to get a hosting site, release the code and build a
>        community?
>
>    Are there any mechanism to help fund such an open-source project?
>
> This is not meant to be a general announcement but rather a means
> for me to get some initial advice as to how to proceed.
>
> Any help is appreciated.
>
> Richard Emberson
>
>
> --
> Quis custodiet ipsos custodes
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

James Carman
In reply to this post by richard emberson
I haven't had time to read all of this (hard to get through it all on
my phone), but I don't think that mere "port" of Wicket to Scala is
what is needed.  I'd rather see a project built for Scala from the
ground up based on some of the concepts from Wicket.  Wicket wasn't
designed with a functional programming language in mind and I think
there are a lot of places where the functional style could simplify
things quite a bit.  I am very interested in seeing what you have put
together.  Are you planning on putting the code up on Github or
something?

On Tue, Jan 4, 2011 at 6:15 PM, richard emberson
<[hidden email]> wrote:

> Dev Wicketers,
>
> What: I have ported Wicket to Scala
>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
>    This encompasses all of the source and test code. As successive 1.5
>    snapshots were released, I ported those differences to my Scala
>    version. I am current with 1.5 M3.
>
>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>    counting all the println statements I put into the Scala code
>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
>    count lines of code.
>
>    I have also replaced all of the Java collection classes with
>    Scala collection classes (though a small number of Java collection
>    classes remain that did not have comparable Scala implementations).
>
>    I have changed many method return types from the Java returning
>    some "object" or "null" to Scala returning "Some(object)" or "None"
>    (using the Scala Option[return-type] construct) - trying to
>    eliminate nulls.
>
>    Lastly, I pushed the IModel[T] typing down to the Component class
>    making get/set DefaultModel and get/set DefaultModelObject strong
>    typed.  This included using Scala companion object apply methods
>    which eliminated having to explicitly declare type parameters in
>    most end-user code (I had read that one of the objections to
>    pushing strong typing down to the Component class in Wicket was
>    that there were "too many notes", end-user code was too verbose).
>
>    It can not interoperate with Java Wicket because Scala compiles to
>    JVM class files and so all of the classes in Java Wicket also
>    appear in Scala-Wicket.
>
>    I have an "internal" name for my Scala port of Wicket which
>    acknowledges its Wicket heritage as well as advertises its
>    enterprise level capabilities. For external communications,
>    I am currently simply call it Scala-Wicket.
>
> Why: Scala is a better Java
>    I was introduced to Scala 9 months ago and quickly determined that
>    it was a better Java (at least IMO). For Scala to succeed it
>    requires more programmers to use it. Many on the Scala mailing
>    lists were from a functional background and seemed not to recognize
>    that Haskell and Lisp are not blindingly successful but, rather,
>    niche languages and that the heavy selling of Scala's function and
>    typing capabilities might turn off Java programmers.
>
>    Scala struck me in many ways as a strong-typed JavaScript, at
>    least, much of the code did not have to have type declarations
>    because the compiler could infer types in many cases. In addition,
>    a whole lot of the Java boil-plate code was not needed. As such,
>    it could be sold as simply a better Java; a more-to-the-point
>    object oriented language with functional programming in-the-small.
>
>    To get more Java programmers to try Scala I looked for a
>    significant Java application with a strong support and user
>    community that I could port to Scala. I ended up with Wicket.
>    Wicket is an enterprise level web framework (unlike existing
>    Scale web frameworks which place restrictions on enterprise IT
>    organizations, e.g., by requiring sticky sessions).  It is well
>    documented. And, as it turned out, very, very importantly it had
>    a large number of unit tests (the unit tests saved my butt,
>    without them I would never had succeeded in getting a port that
>    worked).
>
>    No, Really, Why:
>        I like Scala and I took the time to learn it. Right now about
>        20% of programmers use Java while only some 0.4% use Scala.
>        I did not want my effort of learning Scala to be wasted so my
>        solution is to increase the number of Scala programmers. Where
>        to get them? Again, my solution is from the existing horde of
>        Java programmers.
>
> Plans: Release, Evolve and Proselytize
>    I would like to release Scala-Wicket.
>    I do not know if Apache hosts anything other than Java code.
>    Growing a community is important.
>
>    Still Todo:
>        Comments: All of the existing class and inline comments are
>            still Java related.  This would have to be a long, on-going
>            task to edit the comments so they reflect the code's
>            Scala usage.
>        Package path: The code still uses the "org.apache.wicket"
>            package path and this must be changed - unless this became
>            an Apache project.
>        Author: I have quite literally looked at and touched every line
>            of code but I have not yet felt comfortable with adding
>            myself as an author since, well, many changes were
>            syntactic and not semantic.
>        Refactor with Traits: Currently the port uses Scala traits like
>            Java interfaces but it should be possible to factor the
>            common code out into the traits. This would result in many
>            of the interfaces, the "I" files, such as IModel.scala,
>            going away.
>        Some general refactoring:
>            As an example, consider factoring out the IModel[T] from
>            Component. Half the time a user wants a Component with
>            no model, so, if there was a HasModel trait:
>                class Model[T](var value: T) {
>                    def getObject: T = value
>                    def setObject(value: T): Unit = this.value = value
>                }
>                trait HasModel[T] {
>                  var model: Model[T]
>                  def getDefaultModel: IModel[T] = model
>                  def setDefaultModel(model: IModel[T]): this.type = {
>                    ....
>                    this
>                  }
>                  def getDefaultModelObject: Option[T] = {
>                    ....
>                  }
>                  def setDefaultModelObject(obj: T): this.type = {
>                    ....
>                    this
>                  }
>                }
>            The Component hierarchy would have no model support.
>            The user could add model support when needed:
>                val form = new Form("hi")
>                  with HasModel[Int] { var model = new Model(42) }
>            Just an Idea.
>        STM: There are a number of Scala STM projects and I do not know
>            if it is useful to add STM capabilities to Scala-Wicket.
>        RBAC: I've written a Scala implementation of the NIST RBAC
>            recommended standard and might consider adding it.
>        Logging: Adding a Scala-based logging framework to aid user
>            debugging.
>        Monitoring and stats: In the last couple of years many web
>            sites have added monitoring and statistics gathering
>            capabilities (e.g., who clicks what, where, how long, on
>            what page does the visitor exit the web site, etc.) in
>            order to know how the web site is being used and then
>            improve the web site.
>        Significant Memory Usage Reduction: I've an idea that would
>            significantly decrease the memory usage of Scala-Wicket and
>            I plan to do a test implementation.
>        Replace Java features: There are still some Java-isms that can
>            be replaced with Scala equivalents.
>        Port additional Java Wicket libraries to Scala.
>        Enable multiple instances of a unit tests to be run at once.
>        More: ????????????
>
>    I want to avoid using some of the WTF features of Scala (when a
>        Java programmer looks at the code and says "WTF") in order to
>        ease and accelerate acceptance by Java programmers; as
>        examples, implicits can make code hard to understand and
>        advanced Scala type usages, as James Gosling said, "makes one's
>        head spin".
>
>
> Help and Advice: How should Scala-Wicket be extended and released
>
>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
>        re-write. Given that, what would you do differently in Wicket
>        now that there are years of experience using it?
>
>    How best to get a hosting site, release the code and build a
>        community?
>
>    Are there any mechanism to help fund such an open-source project?
>
> This is not meant to be a general announcement but rather a means
> for me to get some initial advice as to how to proceed.
>
> Any help is appreciated.
>
> Richard Emberson
>
>
> --
> Quis custodiet ipsos custodes
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

jeremy@wickettraining.com
In reply to this post by richard emberson
On Tue, Jan 4, 2011 at 5:15 PM, richard emberson <[hidden email]
> wrote:

> Dev Wicketers,
>
> What: I have ported Wicket to Scala
>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
>    This encompasses all of the source and test code. As successive 1.5
>    snapshots were released, I ported those differences to my Scala
>    version. I am current with 1.5 M3.
>
>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>    counting all the println statements I put into the Scala code
>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
>    count lines of code.
>

I haven't used CLOC before.  I've used Ohcount (
http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a try.


   I have also replaced all of the Java collection classes with

>    Scala collection classes (though a small number of Java collection
>    classes remain that did not have comparable Scala implementations).
>
>    I have changed many method return types from the Java returning
>    some "object" or "null" to Scala returning "Some(object)" or "None"
>    (using the Scala Option[return-type] construct) - trying to
>    eliminate nulls.
>
>    Lastly, I pushed the IModel[T] typing down to the Component class
>    making get/set DefaultModel and get/set DefaultModelObject strong
>    typed.  This included using Scala companion object apply methods
>    which eliminated having to explicitly declare type parameters in
>    most end-user code (I had read that one of the objections to
>    pushing strong typing down to the Component class in Wicket was
>    that there were "too many notes", end-user code was too verbose).
>
>    It can not interoperate with Java Wicket because Scala compiles to
>    JVM class files and so all of the classes in Java Wicket also
>    appear in Scala-Wicket.


>    I have an "internal" name for my Scala port of Wicket which
>    acknowledges its Wicket heritage as well as advertises its
>    enterprise level capabilities. For external communications,
>    I am currently simply call it Scala-Wicket.
>
> Why: Scala is a better Java
>    I was introduced to Scala 9 months ago and quickly determined that
>    it was a better Java (at least IMO). For Scala to succeed it
>    requires more programmers to use it. Many on the Scala mailing
>    lists were from a functional background and seemed not to recognize
>    that Haskell and Lisp are not blindingly successful but, rather,
>    niche languages and that the heavy selling of Scala's function and
>    typing capabilities might turn off Java programmers.
>
>    Scala struck me in many ways as a strong-typed JavaScript, at
>    least, much of the code did not have to have type declarations
>    because the compiler could infer types in many cases. In addition,
>    a whole lot of the Java boil-plate code was not needed. As such,
>    it could be sold as simply a better Java; a more-to-the-point
>    object oriented language with functional programming in-the-small.
>
>    To get more Java programmers to try Scala I looked for a
>    significant Java application with a strong support and user
>    community that I could port to Scala. I ended up with Wicket.
>    Wicket is an enterprise level web framework (unlike existing
>    Scale web frameworks which place restrictions on enterprise IT
>    organizations, e.g., by requiring sticky sessions).  It is well
>    documented. And, as it turned out, very, very importantly it had
>    a large number of unit tests (the unit tests saved my butt,
>    without them I would never had succeeded in getting a port that
>    worked).
>
>    No, Really, Why:
>        I like Scala and I took the time to learn it. Right now about
>        20% of programmers use Java while only some 0.4% use Scala.
>        I did not want my effort of learning Scala to be wasted so my
>        solution is to increase the number of Scala programmers. Where
>        to get them? Again, my solution is from the existing horde of
>        Java programmers.
>
> Plans: Release, Evolve and Proselytize
>    I would like to release Scala-Wicket.
>    I do not know if Apache hosts anything other than Java code.
>    Growing a community is important.
>
>    Still Todo:
>        Comments: All of the existing class and inline comments are
>            still Java related.  This would have to be a long, on-going
>            task to edit the comments so they reflect the code's
>            Scala usage.
>        Package path: The code still uses the "org.apache.wicket"
>            package path and this must be changed - unless this became
>            an Apache project.
>        Author: I have quite literally looked at and touched every line
>            of code but I have not yet felt comfortable with adding
>            myself as an author since, well, many changes were
>            syntactic and not semantic.
>        Refactor with Traits: Currently the port uses Scala traits like
>            Java interfaces but it should be possible to factor the
>            common code out into the traits. This would result in many
>            of the interfaces, the "I" files, such as IModel.scala,
>            going away.
>        Some general refactoring:
>            As an example, consider factoring out the IModel[T] from
>            Component. Half the time a user wants a Component with
>            no model, so, if there was a HasModel trait:
>                class Model[T](var value: T) {
>                    def getObject: T = value
>                    def setObject(value: T): Unit = this.value = value
>                }
>                trait HasModel[T] {
>                  var model: Model[T]
>                  def getDefaultModel: IModel[T] = model
>                  def setDefaultModel(model: IModel[T]): this.type = {
>                    ....
>                    this
>                  }
>                  def getDefaultModelObject: Option[T] = {
>                    ....
>                  }
>                  def setDefaultModelObject(obj: T): this.type = {
>                    ....
>                    this
>                  }
>                }
>            The Component hierarchy would have no model support.
>            The user could add model support when needed:
>                val form = new Form("hi")
>                  with HasModel[Int] { var model = new Model(42) }
>            Just an Idea.
>        STM: There are a number of Scala STM projects and I do not know
>            if it is useful to add STM capabilities to Scala-Wicket.
>        RBAC: I've written a Scala implementation of the NIST RBAC
>            recommended standard and might consider adding it.
>        Logging: Adding a Scala-based logging framework to aid user
>            debugging.
>        Monitoring and stats: In the last couple of years many web
>            sites have added monitoring and statistics gathering
>            capabilities (e.g., who clicks what, where, how long, on
>            what page does the visitor exit the web site, etc.) in
>            order to know how the web site is being used and then
>            improve the web site.
>        Significant Memory Usage Reduction: I've an idea that would
>            significantly decrease the memory usage of Scala-Wicket and
>            I plan to do a test implementation.
>        Replace Java features: There are still some Java-isms that can
>            be replaced with Scala equivalents.
>        Port additional Java Wicket libraries to Scala.
>        Enable multiple instances of a unit tests to be run at once.
>        More: ????????????
>
>    I want to avoid using some of the WTF features of Scala (when a
>        Java programmer looks at the code and says "WTF") in order to
>        ease and accelerate acceptance by Java programmers; as
>        examples, implicits can make code hard to understand and
>        advanced Scala type usages, as James Gosling said, "makes one's
>        head spin".
>
>
> Help and Advice: How should Scala-Wicket be extended and released
>
>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
>        re-write. Given that, what would you do differently in Wicket
>        now that there are years of experience using it?
>
>    How best to get a hosting site, release the code and build a
>        community?
>

If you're looking for a place to host it, I'd recommend starting with
Github.  Git is where the crowd is headed, and Github is the easiest place
to get up and running with it these days.

You mentioned earlier the idea of it being an Apache project.  If you wanted
it to be an Apache project, you would start at the Incubator (
http://incubator.apache.org/).  The one barrier you'll have initially is
that Apache favors "community over code"... so it's not a great place to
start a one-man project.  Since this is a port of an existing Apache
project, you might have more leniency, but you'd have to build a community
around the project before you could ever "graduate" from the incubator.

Probably Github is your best bet for now.  Build a community.  Then, if your
community is in favor, move to Apache.  By that time, ASF might have full
git support.


>    Are there any mechanism to help fund such an open-source project?
>

Best bet is to build a community.  Of course, if you can find some company
that wants such a project, you can get monetary support to develop /
maintain.  But that seems unlikely in this case with the limited number of
companies looking for Scala out there, and especially since this is an
unproven port of a large Java project.  So, start by getting folks like
jWeekend involved - great coders who are already salivating for Scala.  Find
other individuals such as yourself who are interested, and build a group of
core committers.


> This is not meant to be a general announcement but rather a means
> for me to get some initial advice as to how to proceed.
>
> Any help is appreciated.
>
> Richard Emberson


I'm impressed.  Quite an undertaking.

--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

jdonnerstag
Cool. May I ask which tools (IDE) you've been using and what your
experience with these tools has been.

-Juergen

On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
<[hidden email]> wrote:

> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson <[hidden email]
>> wrote:
>
>> Dev Wicketers,
>>
>> What: I have ported Wicket to Scala
>>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
>>    This encompasses all of the source and test code. As successive 1.5
>>    snapshots were released, I ported those differences to my Scala
>>    version. I am current with 1.5 M3.
>>
>>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>>    counting all the println statements I put into the Scala code
>>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
>>    count lines of code.
>>
>
> I haven't used CLOC before.  I've used Ohcount (
> http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a try.
>
>
>   I have also replaced all of the Java collection classes with
>>    Scala collection classes (though a small number of Java collection
>>    classes remain that did not have comparable Scala implementations).
>>
>>    I have changed many method return types from the Java returning
>>    some "object" or "null" to Scala returning "Some(object)" or "None"
>>    (using the Scala Option[return-type] construct) - trying to
>>    eliminate nulls.
>>
>>    Lastly, I pushed the IModel[T] typing down to the Component class
>>    making get/set DefaultModel and get/set DefaultModelObject strong
>>    typed.  This included using Scala companion object apply methods
>>    which eliminated having to explicitly declare type parameters in
>>    most end-user code (I had read that one of the objections to
>>    pushing strong typing down to the Component class in Wicket was
>>    that there were "too many notes", end-user code was too verbose).
>>
>>    It can not interoperate with Java Wicket because Scala compiles to
>>    JVM class files and so all of the classes in Java Wicket also
>>    appear in Scala-Wicket.
>
>
>>    I have an "internal" name for my Scala port of Wicket which
>>    acknowledges its Wicket heritage as well as advertises its
>>    enterprise level capabilities. For external communications,
>>    I am currently simply call it Scala-Wicket.
>>
>> Why: Scala is a better Java
>>    I was introduced to Scala 9 months ago and quickly determined that
>>    it was a better Java (at least IMO). For Scala to succeed it
>>    requires more programmers to use it. Many on the Scala mailing
>>    lists were from a functional background and seemed not to recognize
>>    that Haskell and Lisp are not blindingly successful but, rather,
>>    niche languages and that the heavy selling of Scala's function and
>>    typing capabilities might turn off Java programmers.
>>
>>    Scala struck me in many ways as a strong-typed JavaScript, at
>>    least, much of the code did not have to have type declarations
>>    because the compiler could infer types in many cases. In addition,
>>    a whole lot of the Java boil-plate code was not needed. As such,
>>    it could be sold as simply a better Java; a more-to-the-point
>>    object oriented language with functional programming in-the-small.
>>
>>    To get more Java programmers to try Scala I looked for a
>>    significant Java application with a strong support and user
>>    community that I could port to Scala. I ended up with Wicket.
>>    Wicket is an enterprise level web framework (unlike existing
>>    Scale web frameworks which place restrictions on enterprise IT
>>    organizations, e.g., by requiring sticky sessions).  It is well
>>    documented. And, as it turned out, very, very importantly it had
>>    a large number of unit tests (the unit tests saved my butt,
>>    without them I would never had succeeded in getting a port that
>>    worked).
>>
>>    No, Really, Why:
>>        I like Scala and I took the time to learn it. Right now about
>>        20% of programmers use Java while only some 0.4% use Scala.
>>        I did not want my effort of learning Scala to be wasted so my
>>        solution is to increase the number of Scala programmers. Where
>>        to get them? Again, my solution is from the existing horde of
>>        Java programmers.
>>
>> Plans: Release, Evolve and Proselytize
>>    I would like to release Scala-Wicket.
>>    I do not know if Apache hosts anything other than Java code.
>>    Growing a community is important.
>>
>>    Still Todo:
>>        Comments: All of the existing class and inline comments are
>>            still Java related.  This would have to be a long, on-going
>>            task to edit the comments so they reflect the code's
>>            Scala usage.
>>        Package path: The code still uses the "org.apache.wicket"
>>            package path and this must be changed - unless this became
>>            an Apache project.
>>        Author: I have quite literally looked at and touched every line
>>            of code but I have not yet felt comfortable with adding
>>            myself as an author since, well, many changes were
>>            syntactic and not semantic.
>>        Refactor with Traits: Currently the port uses Scala traits like
>>            Java interfaces but it should be possible to factor the
>>            common code out into the traits. This would result in many
>>            of the interfaces, the "I" files, such as IModel.scala,
>>            going away.
>>        Some general refactoring:
>>            As an example, consider factoring out the IModel[T] from
>>            Component. Half the time a user wants a Component with
>>            no model, so, if there was a HasModel trait:
>>                class Model[T](var value: T) {
>>                    def getObject: T = value
>>                    def setObject(value: T): Unit = this.value = value
>>                }
>>                trait HasModel[T] {
>>                  var model: Model[T]
>>                  def getDefaultModel: IModel[T] = model
>>                  def setDefaultModel(model: IModel[T]): this.type = {
>>                    ....
>>                    this
>>                  }
>>                  def getDefaultModelObject: Option[T] = {
>>                    ....
>>                  }
>>                  def setDefaultModelObject(obj: T): this.type = {
>>                    ....
>>                    this
>>                  }
>>                }
>>            The Component hierarchy would have no model support.
>>            The user could add model support when needed:
>>                val form = new Form("hi")
>>                  with HasModel[Int] { var model = new Model(42) }
>>            Just an Idea.
>>        STM: There are a number of Scala STM projects and I do not know
>>            if it is useful to add STM capabilities to Scala-Wicket.
>>        RBAC: I've written a Scala implementation of the NIST RBAC
>>            recommended standard and might consider adding it.
>>        Logging: Adding a Scala-based logging framework to aid user
>>            debugging.
>>        Monitoring and stats: In the last couple of years many web
>>            sites have added monitoring and statistics gathering
>>            capabilities (e.g., who clicks what, where, how long, on
>>            what page does the visitor exit the web site, etc.) in
>>            order to know how the web site is being used and then
>>            improve the web site.
>>        Significant Memory Usage Reduction: I've an idea that would
>>            significantly decrease the memory usage of Scala-Wicket and
>>            I plan to do a test implementation.
>>        Replace Java features: There are still some Java-isms that can
>>            be replaced with Scala equivalents.
>>        Port additional Java Wicket libraries to Scala.
>>        Enable multiple instances of a unit tests to be run at once.
>>        More: ????????????
>>
>>    I want to avoid using some of the WTF features of Scala (when a
>>        Java programmer looks at the code and says "WTF") in order to
>>        ease and accelerate acceptance by Java programmers; as
>>        examples, implicits can make code hard to understand and
>>        advanced Scala type usages, as James Gosling said, "makes one's
>>        head spin".
>>
>>
>> Help and Advice: How should Scala-Wicket be extended and released
>>
>>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
>>        re-write. Given that, what would you do differently in Wicket
>>        now that there are years of experience using it?
>>
>>    How best to get a hosting site, release the code and build a
>>        community?
>>
>
> If you're looking for a place to host it, I'd recommend starting with
> Github.  Git is where the crowd is headed, and Github is the easiest place
> to get up and running with it these days.
>
> You mentioned earlier the idea of it being an Apache project.  If you wanted
> it to be an Apache project, you would start at the Incubator (
> http://incubator.apache.org/).  The one barrier you'll have initially is
> that Apache favors "community over code"... so it's not a great place to
> start a one-man project.  Since this is a port of an existing Apache
> project, you might have more leniency, but you'd have to build a community
> around the project before you could ever "graduate" from the incubator.
>
> Probably Github is your best bet for now.  Build a community.  Then, if your
> community is in favor, move to Apache.  By that time, ASF might have full
> git support.
>
>
>>    Are there any mechanism to help fund such an open-source project?
>>
>
> Best bet is to build a community.  Of course, if you can find some company
> that wants such a project, you can get monetary support to develop /
> maintain.  But that seems unlikely in this case with the limited number of
> companies looking for Scala out there, and especially since this is an
> unproven port of a large Java project.  So, start by getting folks like
> jWeekend involved - great coders who are already salivating for Scala.  Find
> other individuals such as yourself who are interested, and build a group of
> core committers.
>
>
>> This is not meant to be a general announcement but rather a means
>> for me to get some initial advice as to how to proceed.
>>
>> Any help is appreciated.
>>
>> Richard Emberson
>
>
> I'm impressed.  Quite an undertaking.
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Martin Grigorov-4
On Wed, Jan 5, 2011 at 9:38 AM, Juergen Donnerstag <
[hidden email]> wrote:

> Cool. May I ask which tools (IDE) you've been using and what your
> experience with these tools has been.
>

#scala suggests IDEA 10 + SBT plugin as the most mature one.


>
> -Juergen
>
> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
> <[hidden email]> wrote:
> > On Tue, Jan 4, 2011 at 5:15 PM, richard emberson <
> [hidden email]
> >> wrote:
> >
> >> Dev Wicketers,
> >>
> >> What: I have ported Wicket to Scala
> >>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
> >>    This encompasses all of the source and test code. As successive 1.5
> >>    snapshots were released, I ported those differences to my Scala
> >>    version. I am current with 1.5 M3.
> >>
> >>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
> >>    counting all the println statements I put into the Scala code
> >>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
> >>    count lines of code.
> >>
> >
> > I haven't used CLOC before.  I've used Ohcount (
> > http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a
> try.
> >
> >
> >   I have also replaced all of the Java collection classes with
> >>    Scala collection classes (though a small number of Java collection
> >>    classes remain that did not have comparable Scala implementations).
> >>
> >>    I have changed many method return types from the Java returning
> >>    some "object" or "null" to Scala returning "Some(object)" or "None"
> >>    (using the Scala Option[return-type] construct) - trying to
> >>    eliminate nulls.
> >>
> >>    Lastly, I pushed the IModel[T] typing down to the Component class
> >>    making get/set DefaultModel and get/set DefaultModelObject strong
> >>    typed.  This included using Scala companion object apply methods
> >>    which eliminated having to explicitly declare type parameters in
> >>    most end-user code (I had read that one of the objections to
> >>    pushing strong typing down to the Component class in Wicket was
> >>    that there were "too many notes", end-user code was too verbose).
> >>
> >>    It can not interoperate with Java Wicket because Scala compiles to
> >>    JVM class files and so all of the classes in Java Wicket also
> >>    appear in Scala-Wicket.
> >
> >
> >>    I have an "internal" name for my Scala port of Wicket which
> >>    acknowledges its Wicket heritage as well as advertises its
> >>    enterprise level capabilities. For external communications,
> >>    I am currently simply call it Scala-Wicket.
> >>
> >> Why: Scala is a better Java
> >>    I was introduced to Scala 9 months ago and quickly determined that
> >>    it was a better Java (at least IMO). For Scala to succeed it
> >>    requires more programmers to use it. Many on the Scala mailing
> >>    lists were from a functional background and seemed not to recognize
> >>    that Haskell and Lisp are not blindingly successful but, rather,
> >>    niche languages and that the heavy selling of Scala's function and
> >>    typing capabilities might turn off Java programmers.
> >>
> >>    Scala struck me in many ways as a strong-typed JavaScript, at
> >>    least, much of the code did not have to have type declarations
> >>    because the compiler could infer types in many cases. In addition,
> >>    a whole lot of the Java boil-plate code was not needed. As such,
> >>    it could be sold as simply a better Java; a more-to-the-point
> >>    object oriented language with functional programming in-the-small.
> >>
> >>    To get more Java programmers to try Scala I looked for a
> >>    significant Java application with a strong support and user
> >>    community that I could port to Scala. I ended up with Wicket.
> >>    Wicket is an enterprise level web framework (unlike existing
> >>    Scale web frameworks which place restrictions on enterprise IT
> >>    organizations, e.g., by requiring sticky sessions).  It is well
> >>    documented. And, as it turned out, very, very importantly it had
> >>    a large number of unit tests (the unit tests saved my butt,
> >>    without them I would never had succeeded in getting a port that
> >>    worked).
> >>
> >>    No, Really, Why:
> >>        I like Scala and I took the time to learn it. Right now about
> >>        20% of programmers use Java while only some 0.4% use Scala.
> >>        I did not want my effort of learning Scala to be wasted so my
> >>        solution is to increase the number of Scala programmers. Where
> >>        to get them? Again, my solution is from the existing horde of
> >>        Java programmers.
> >>
> >> Plans: Release, Evolve and Proselytize
> >>    I would like to release Scala-Wicket.
> >>    I do not know if Apache hosts anything other than Java code.
> >>    Growing a community is important.
> >>
> >>    Still Todo:
> >>        Comments: All of the existing class and inline comments are
> >>            still Java related.  This would have to be a long, on-going
> >>            task to edit the comments so they reflect the code's
> >>            Scala usage.
> >>        Package path: The code still uses the "org.apache.wicket"
> >>            package path and this must be changed - unless this became
> >>            an Apache project.
> >>        Author: I have quite literally looked at and touched every line
> >>            of code but I have not yet felt comfortable with adding
> >>            myself as an author since, well, many changes were
> >>            syntactic and not semantic.
> >>        Refactor with Traits: Currently the port uses Scala traits like
> >>            Java interfaces but it should be possible to factor the
> >>            common code out into the traits. This would result in many
> >>            of the interfaces, the "I" files, such as IModel.scala,
> >>            going away.
> >>        Some general refactoring:
> >>            As an example, consider factoring out the IModel[T] from
> >>            Component. Half the time a user wants a Component with
> >>            no model, so, if there was a HasModel trait:
> >>                class Model[T](var value: T) {
> >>                    def getObject: T = value
> >>                    def setObject(value: T): Unit = this.value = value
> >>                }
> >>                trait HasModel[T] {
> >>                  var model: Model[T]
> >>                  def getDefaultModel: IModel[T] = model
> >>                  def setDefaultModel(model: IModel[T]): this.type = {
> >>                    ....
> >>                    this
> >>                  }
> >>                  def getDefaultModelObject: Option[T] = {
> >>                    ....
> >>                  }
> >>                  def setDefaultModelObject(obj: T): this.type = {
> >>                    ....
> >>                    this
> >>                  }
> >>                }
> >>            The Component hierarchy would have no model support.
> >>            The user could add model support when needed:
> >>                val form = new Form("hi")
> >>                  with HasModel[Int] { var model = new Model(42) }
> >>            Just an Idea.
> >>        STM: There are a number of Scala STM projects and I do not know
> >>            if it is useful to add STM capabilities to Scala-Wicket.
> >>        RBAC: I've written a Scala implementation of the NIST RBAC
> >>            recommended standard and might consider adding it.
> >>        Logging: Adding a Scala-based logging framework to aid user
> >>            debugging.
> >>        Monitoring and stats: In the last couple of years many web
> >>            sites have added monitoring and statistics gathering
> >>            capabilities (e.g., who clicks what, where, how long, on
> >>            what page does the visitor exit the web site, etc.) in
> >>            order to know how the web site is being used and then
> >>            improve the web site.
> >>        Significant Memory Usage Reduction: I've an idea that would
> >>            significantly decrease the memory usage of Scala-Wicket and
> >>            I plan to do a test implementation.
> >>        Replace Java features: There are still some Java-isms that can
> >>            be replaced with Scala equivalents.
> >>        Port additional Java Wicket libraries to Scala.
> >>        Enable multiple instances of a unit tests to be run at once.
> >>        More: ????????????
> >>
> >>    I want to avoid using some of the WTF features of Scala (when a
> >>        Java programmer looks at the code and says "WTF") in order to
> >>        ease and accelerate acceptance by Java programmers; as
> >>        examples, implicits can make code hard to understand and
> >>        advanced Scala type usages, as James Gosling said, "makes one's
> >>        head spin".
> >>
> >>
> >> Help and Advice: How should Scala-Wicket be extended and released
> >>
> >>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
> >>        re-write. Given that, what would you do differently in Wicket
> >>        now that there are years of experience using it?
> >>
> >>    How best to get a hosting site, release the code and build a
> >>        community?
> >>
> >
> > If you're looking for a place to host it, I'd recommend starting with
> > Github.  Git is where the crowd is headed, and Github is the easiest
> place
> > to get up and running with it these days.
> >
> > You mentioned earlier the idea of it being an Apache project.  If you
> wanted
> > it to be an Apache project, you would start at the Incubator (
> > http://incubator.apache.org/).  The one barrier you'll have initially is
> > that Apache favors "community over code"... so it's not a great place to
> > start a one-man project.  Since this is a port of an existing Apache
> > project, you might have more leniency, but you'd have to build a
> community
> > around the project before you could ever "graduate" from the incubator.
> >
> > Probably Github is your best bet for now.  Build a community.  Then, if
> your
> > community is in favor, move to Apache.  By that time, ASF might have full
> > git support.
> >
> >
> >>    Are there any mechanism to help fund such an open-source project?
> >>
> >
> > Best bet is to build a community.  Of course, if you can find some
> company
> > that wants such a project, you can get monetary support to develop /
> > maintain.  But that seems unlikely in this case with the limited number
> of
> > companies looking for Scala out there, and especially since this is an
> > unproven port of a large Java project.  So, start by getting folks like
> > jWeekend involved - great coders who are already salivating for Scala.
>  Find
> > other individuals such as yourself who are interested, and build a group
> of
> > core committers.
> >
> >
> >> This is not meant to be a general announcement but rather a means
> >> for me to get some initial advice as to how to proceed.
> >>
> >> Any help is appreciated.
> >>
> >> Richard Emberson
> >
> >
> > I'm impressed.  Quite an undertaking.
> >
> > --
> > Jeremy Thomerson
> > http://wickettraining.com
> > *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

richard emberson
In reply to this post by jdonnerstag
No IDE, I use Vim. Also, my build environment is Ant-based
using scalac and javac.

Of course, what I was doing was porting from Java to Scala.
To that end I've got some 400 Vim scripts that aid in the
port. For instance,

:g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g

converts
     final B a[] =
to
     val a: Array[B] =

I don't know if IDEs provide such scripting with regex support.
Also, with a simple Vim script and key combination, I can be
viewing a ported Scala file and jump to its corresponding source
Java Wicket file - very useful when porting or debugging.
Yea, IDEs can do stuff me and my Vim scripts can not do, but my
fingers know Vim.

I also built a JUnit driver class in Scala (and Java) that allowed
me to execute a single test method in a given test class by setting
two properties in a file that my Ant script reads. This was vital
for hunting down bugs.

I looked into the tool that allowed Vim to be the front-end and
Eclipse to run in server mode which allows a Vim user to access
many of the extra features the IDE offers, but, as of a couple of
months ago, there was no Scala support in the tool.

The father of Scala, Martin Odersky uses Emacs.

Richard


On 01/05/2011 12:38 AM, Juergen Donnerstag wrote:

> Cool. May I ask which tools (IDE) you've been using and what your
> experience with these tools has been.
>
> -Juergen
>
> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
> <[hidden email]>  wrote:
>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<[hidden email]
>>> wrote:
>>
>>> Dev Wicketers,
>>>
>>> What: I have ported Wicket to Scala
>>>     A couple of months ago I took a 1.5 snapshot and ported to Scala.
>>>     This encompasses all of the source and test code. As successive 1.5
>>>     snapshots were released, I ported those differences to my Scala
>>>     version. I am current with 1.5 M3.
>>>
>>>     The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>>>     counting all the println statements I put into the Scala code
>>>     for debugging). I used cloc (http://cloc.sourceforge.net/) to
>>>     count lines of code.
>>>
>>
>> I haven't used CLOC before.  I've used Ohcount (
>> http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a try.
>>
>>
>>    I have also replaced all of the Java collection classes with
>>>     Scala collection classes (though a small number of Java collection
>>>     classes remain that did not have comparable Scala implementations).
>>>
>>>     I have changed many method return types from the Java returning
>>>     some "object" or "null" to Scala returning "Some(object)" or "None"
>>>     (using the Scala Option[return-type] construct) - trying to
>>>     eliminate nulls.
>>>
>>>     Lastly, I pushed the IModel[T] typing down to the Component class
>>>     making get/set DefaultModel and get/set DefaultModelObject strong
>>>     typed.  This included using Scala companion object apply methods
>>>     which eliminated having to explicitly declare type parameters in
>>>     most end-user code (I had read that one of the objections to
>>>     pushing strong typing down to the Component class in Wicket was
>>>     that there were "too many notes", end-user code was too verbose).
>>>
>>>     It can not interoperate with Java Wicket because Scala compiles to
>>>     JVM class files and so all of the classes in Java Wicket also
>>>     appear in Scala-Wicket.
>>
>>
>>>     I have an "internal" name for my Scala port of Wicket which
>>>     acknowledges its Wicket heritage as well as advertises its
>>>     enterprise level capabilities. For external communications,
>>>     I am currently simply call it Scala-Wicket.
>>>
>>> Why: Scala is a better Java
>>>     I was introduced to Scala 9 months ago and quickly determined that
>>>     it was a better Java (at least IMO). For Scala to succeed it
>>>     requires more programmers to use it. Many on the Scala mailing
>>>     lists were from a functional background and seemed not to recognize
>>>     that Haskell and Lisp are not blindingly successful but, rather,
>>>     niche languages and that the heavy selling of Scala's function and
>>>     typing capabilities might turn off Java programmers.
>>>
>>>     Scala struck me in many ways as a strong-typed JavaScript, at
>>>     least, much of the code did not have to have type declarations
>>>     because the compiler could infer types in many cases. In addition,
>>>     a whole lot of the Java boil-plate code was not needed. As such,
>>>     it could be sold as simply a better Java; a more-to-the-point
>>>     object oriented language with functional programming in-the-small.
>>>
>>>     To get more Java programmers to try Scala I looked for a
>>>     significant Java application with a strong support and user
>>>     community that I could port to Scala. I ended up with Wicket.
>>>     Wicket is an enterprise level web framework (unlike existing
>>>     Scale web frameworks which place restrictions on enterprise IT
>>>     organizations, e.g., by requiring sticky sessions).  It is well
>>>     documented. And, as it turned out, very, very importantly it had
>>>     a large number of unit tests (the unit tests saved my butt,
>>>     without them I would never had succeeded in getting a port that
>>>     worked).
>>>
>>>     No, Really, Why:
>>>         I like Scala and I took the time to learn it. Right now about
>>>         20% of programmers use Java while only some 0.4% use Scala.
>>>         I did not want my effort of learning Scala to be wasted so my
>>>         solution is to increase the number of Scala programmers. Where
>>>         to get them? Again, my solution is from the existing horde of
>>>         Java programmers.
>>>
>>> Plans: Release, Evolve and Proselytize
>>>     I would like to release Scala-Wicket.
>>>     I do not know if Apache hosts anything other than Java code.
>>>     Growing a community is important.
>>>
>>>     Still Todo:
>>>         Comments: All of the existing class and inline comments are
>>>             still Java related.  This would have to be a long, on-going
>>>             task to edit the comments so they reflect the code's
>>>             Scala usage.
>>>         Package path: The code still uses the "org.apache.wicket"
>>>             package path and this must be changed - unless this became
>>>             an Apache project.
>>>         Author: I have quite literally looked at and touched every line
>>>             of code but I have not yet felt comfortable with adding
>>>             myself as an author since, well, many changes were
>>>             syntactic and not semantic.
>>>         Refactor with Traits: Currently the port uses Scala traits like
>>>             Java interfaces but it should be possible to factor the
>>>             common code out into the traits. This would result in many
>>>             of the interfaces, the "I" files, such as IModel.scala,
>>>             going away.
>>>         Some general refactoring:
>>>             As an example, consider factoring out the IModel[T] from
>>>             Component. Half the time a user wants a Component with
>>>             no model, so, if there was a HasModel trait:
>>>                 class Model[T](var value: T) {
>>>                     def getObject: T = value
>>>                     def setObject(value: T): Unit = this.value = value
>>>                 }
>>>                 trait HasModel[T] {
>>>                   var model: Model[T]
>>>                   def getDefaultModel: IModel[T] = model
>>>                   def setDefaultModel(model: IModel[T]): this.type = {
>>>                     ....
>>>                     this
>>>                   }
>>>                   def getDefaultModelObject: Option[T] = {
>>>                     ....
>>>                   }
>>>                   def setDefaultModelObject(obj: T): this.type = {
>>>                     ....
>>>                     this
>>>                   }
>>>                 }
>>>             The Component hierarchy would have no model support.
>>>             The user could add model support when needed:
>>>                 val form = new Form("hi")
>>>                   with HasModel[Int] { var model = new Model(42) }
>>>             Just an Idea.
>>>         STM: There are a number of Scala STM projects and I do not know
>>>             if it is useful to add STM capabilities to Scala-Wicket.
>>>         RBAC: I've written a Scala implementation of the NIST RBAC
>>>             recommended standard and might consider adding it.
>>>         Logging: Adding a Scala-based logging framework to aid user
>>>             debugging.
>>>         Monitoring and stats: In the last couple of years many web
>>>             sites have added monitoring and statistics gathering
>>>             capabilities (e.g., who clicks what, where, how long, on
>>>             what page does the visitor exit the web site, etc.) in
>>>             order to know how the web site is being used and then
>>>             improve the web site.
>>>         Significant Memory Usage Reduction: I've an idea that would
>>>             significantly decrease the memory usage of Scala-Wicket and
>>>             I plan to do a test implementation.
>>>         Replace Java features: There are still some Java-isms that can
>>>             be replaced with Scala equivalents.
>>>         Port additional Java Wicket libraries to Scala.
>>>         Enable multiple instances of a unit tests to be run at once.
>>>         More: ????????????
>>>
>>>     I want to avoid using some of the WTF features of Scala (when a
>>>         Java programmer looks at the code and says "WTF") in order to
>>>         ease and accelerate acceptance by Java programmers; as
>>>         examples, implicits can make code hard to understand and
>>>         advanced Scala type usages, as James Gosling said, "makes one's
>>>         head spin".
>>>
>>>
>>> Help and Advice: How should Scala-Wicket be extended and released
>>>
>>>     Scala-Wicket is a port and evolution of Wicket, not a ground-up
>>>         re-write. Given that, what would you do differently in Wicket
>>>         now that there are years of experience using it?
>>>
>>>     How best to get a hosting site, release the code and build a
>>>         community?
>>>
>>
>> If you're looking for a place to host it, I'd recommend starting with
>> Github.  Git is where the crowd is headed, and Github is the easiest place
>> to get up and running with it these days.
>>
>> You mentioned earlier the idea of it being an Apache project.  If you wanted
>> it to be an Apache project, you would start at the Incubator (
>> http://incubator.apache.org/).  The one barrier you'll have initially is
>> that Apache favors "community over code"... so it's not a great place to
>> start a one-man project.  Since this is a port of an existing Apache
>> project, you might have more leniency, but you'd have to build a community
>> around the project before you could ever "graduate" from the incubator.
>>
>> Probably Github is your best bet for now.  Build a community.  Then, if your
>> community is in favor, move to Apache.  By that time, ASF might have full
>> git support.
>>
>>
>>>     Are there any mechanism to help fund such an open-source project?
>>>
>>
>> Best bet is to build a community.  Of course, if you can find some company
>> that wants such a project, you can get monetary support to develop /
>> maintain.  But that seems unlikely in this case with the limited number of
>> companies looking for Scala out there, and especially since this is an
>> unproven port of a large Java project.  So, start by getting folks like
>> jWeekend involved - great coders who are already salivating for Scala.  Find
>> other individuals such as yourself who are interested, and build a group of
>> core committers.
>>
>>
>>> This is not meant to be a general announcement but rather a means
>>> for me to get some initial advice as to how to proceed.
>>>
>>> Any help is appreciated.
>>>
>>> Richard Emberson
>>
>>
>> I'm impressed.  Quite an undertaking.
>>
>> --
>> Jeremy Thomerson
>> http://wickettraining.com
>> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
>>
>

--
Quis custodiet ipsos custodes
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Justin Lee
You can paste a java class into a .scala file and it'll autoconvert.
 there's a shortcut keystroke, too, but i don't remember what it is.

On Wed, Jan 5, 2011 at 10:40 AM, richard emberson <
[hidden email]> wrote:

> No IDE, I use Vim. Also, my build environment is Ant-based
> using scalac and javac.
>
> Of course, what I was doing was porting from Java to Scala.
> To that end I've got some 400 Vim scripts that aid in the
> port. For instance,
>
> :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g
>
> converts
>    final B a[] =
> to
>    val a: Array[B] =
>
> I don't know if IDEs provide such scripting with regex support.
> Also, with a simple Vim script and key combination, I can be
> viewing a ported Scala file and jump to its corresponding source
> Java Wicket file - very useful when porting or debugging.
> Yea, IDEs can do stuff me and my Vim scripts can not do, but my
> fingers know Vim.
>
> I also built a JUnit driver class in Scala (and Java) that allowed
> me to execute a single test method in a given test class by setting
> two properties in a file that my Ant script reads. This was vital
> for hunting down bugs.
>
> I looked into the tool that allowed Vim to be the front-end and
> Eclipse to run in server mode which allows a Vim user to access
> many of the extra features the IDE offers, but, as of a couple of
> months ago, there was no Scala support in the tool.
>
> The father of Scala, Martin Odersky uses Emacs.
>
> Richard
>
>
>
> On 01/05/2011 12:38 AM, Juergen Donnerstag wrote:
>
>> Cool. May I ask which tools (IDE) you've been using and what your
>> experience with these tools has been.
>>
>> -Juergen
>>
>> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
>> <[hidden email]>  wrote:
>>
>>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<
>>> [hidden email]
>>>
>>>> wrote:
>>>>
>>>
>>>  Dev Wicketers,
>>>>
>>>> What: I have ported Wicket to Scala
>>>>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
>>>>    This encompasses all of the source and test code. As successive 1.5
>>>>    snapshots were released, I ported those differences to my Scala
>>>>    version. I am current with 1.5 M3.
>>>>
>>>>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>>>>    counting all the println statements I put into the Scala code
>>>>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
>>>>    count lines of code.
>>>>
>>>>
>>> I haven't used CLOC before.  I've used Ohcount (
>>> http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a
>>> try.
>>>
>>>
>>>   I have also replaced all of the Java collection classes with
>>>
>>>>    Scala collection classes (though a small number of Java collection
>>>>    classes remain that did not have comparable Scala implementations).
>>>>
>>>>    I have changed many method return types from the Java returning
>>>>    some "object" or "null" to Scala returning "Some(object)" or "None"
>>>>    (using the Scala Option[return-type] construct) - trying to
>>>>    eliminate nulls.
>>>>
>>>>    Lastly, I pushed the IModel[T] typing down to the Component class
>>>>    making get/set DefaultModel and get/set DefaultModelObject strong
>>>>    typed.  This included using Scala companion object apply methods
>>>>    which eliminated having to explicitly declare type parameters in
>>>>    most end-user code (I had read that one of the objections to
>>>>    pushing strong typing down to the Component class in Wicket was
>>>>    that there were "too many notes", end-user code was too verbose).
>>>>
>>>>    It can not interoperate with Java Wicket because Scala compiles to
>>>>    JVM class files and so all of the classes in Java Wicket also
>>>>    appear in Scala-Wicket.
>>>>
>>>
>>>
>>>     I have an "internal" name for my Scala port of Wicket which
>>>>    acknowledges its Wicket heritage as well as advertises its
>>>>    enterprise level capabilities. For external communications,
>>>>    I am currently simply call it Scala-Wicket.
>>>>
>>>> Why: Scala is a better Java
>>>>    I was introduced to Scala 9 months ago and quickly determined that
>>>>    it was a better Java (at least IMO). For Scala to succeed it
>>>>    requires more programmers to use it. Many on the Scala mailing
>>>>    lists were from a functional background and seemed not to recognize
>>>>    that Haskell and Lisp are not blindingly successful but, rather,
>>>>    niche languages and that the heavy selling of Scala's function and
>>>>    typing capabilities might turn off Java programmers.
>>>>
>>>>    Scala struck me in many ways as a strong-typed JavaScript, at
>>>>    least, much of the code did not have to have type declarations
>>>>    because the compiler could infer types in many cases. In addition,
>>>>    a whole lot of the Java boil-plate code was not needed. As such,
>>>>    it could be sold as simply a better Java; a more-to-the-point
>>>>    object oriented language with functional programming in-the-small.
>>>>
>>>>    To get more Java programmers to try Scala I looked for a
>>>>    significant Java application with a strong support and user
>>>>    community that I could port to Scala. I ended up with Wicket.
>>>>    Wicket is an enterprise level web framework (unlike existing
>>>>    Scale web frameworks which place restrictions on enterprise IT
>>>>    organizations, e.g., by requiring sticky sessions).  It is well
>>>>    documented. And, as it turned out, very, very importantly it had
>>>>    a large number of unit tests (the unit tests saved my butt,
>>>>    without them I would never had succeeded in getting a port that
>>>>    worked).
>>>>
>>>>    No, Really, Why:
>>>>        I like Scala and I took the time to learn it. Right now about
>>>>        20% of programmers use Java while only some 0.4% use Scala.
>>>>        I did not want my effort of learning Scala to be wasted so my
>>>>        solution is to increase the number of Scala programmers. Where
>>>>        to get them? Again, my solution is from the existing horde of
>>>>        Java programmers.
>>>>
>>>> Plans: Release, Evolve and Proselytize
>>>>    I would like to release Scala-Wicket.
>>>>    I do not know if Apache hosts anything other than Java code.
>>>>    Growing a community is important.
>>>>
>>>>    Still Todo:
>>>>        Comments: All of the existing class and inline comments are
>>>>            still Java related.  This would have to be a long, on-going
>>>>            task to edit the comments so they reflect the code's
>>>>            Scala usage.
>>>>        Package path: The code still uses the "org.apache.wicket"
>>>>            package path and this must be changed - unless this became
>>>>            an Apache project.
>>>>        Author: I have quite literally looked at and touched every line
>>>>            of code but I have not yet felt comfortable with adding
>>>>            myself as an author since, well, many changes were
>>>>            syntactic and not semantic.
>>>>        Refactor with Traits: Currently the port uses Scala traits like
>>>>            Java interfaces but it should be possible to factor the
>>>>            common code out into the traits. This would result in many
>>>>            of the interfaces, the "I" files, such as IModel.scala,
>>>>            going away.
>>>>        Some general refactoring:
>>>>            As an example, consider factoring out the IModel[T] from
>>>>            Component. Half the time a user wants a Component with
>>>>            no model, so, if there was a HasModel trait:
>>>>                class Model[T](var value: T) {
>>>>                    def getObject: T = value
>>>>                    def setObject(value: T): Unit = this.value = value
>>>>                }
>>>>                trait HasModel[T] {
>>>>                  var model: Model[T]
>>>>                  def getDefaultModel: IModel[T] = model
>>>>                  def setDefaultModel(model: IModel[T]): this.type = {
>>>>                    ....
>>>>                    this
>>>>                  }
>>>>                  def getDefaultModelObject: Option[T] = {
>>>>                    ....
>>>>                  }
>>>>                  def setDefaultModelObject(obj: T): this.type = {
>>>>                    ....
>>>>                    this
>>>>                  }
>>>>                }
>>>>            The Component hierarchy would have no model support.
>>>>            The user could add model support when needed:
>>>>                val form = new Form("hi")
>>>>                  with HasModel[Int] { var model = new Model(42) }
>>>>            Just an Idea.
>>>>        STM: There are a number of Scala STM projects and I do not know
>>>>            if it is useful to add STM capabilities to Scala-Wicket.
>>>>        RBAC: I've written a Scala implementation of the NIST RBAC
>>>>            recommended standard and might consider adding it.
>>>>        Logging: Adding a Scala-based logging framework to aid user
>>>>            debugging.
>>>>        Monitoring and stats: In the last couple of years many web
>>>>            sites have added monitoring and statistics gathering
>>>>            capabilities (e.g., who clicks what, where, how long, on
>>>>            what page does the visitor exit the web site, etc.) in
>>>>            order to know how the web site is being used and then
>>>>            improve the web site.
>>>>        Significant Memory Usage Reduction: I've an idea that would
>>>>            significantly decrease the memory usage of Scala-Wicket and
>>>>            I plan to do a test implementation.
>>>>        Replace Java features: There are still some Java-isms that can
>>>>            be replaced with Scala equivalents.
>>>>        Port additional Java Wicket libraries to Scala.
>>>>        Enable multiple instances of a unit tests to be run at once.
>>>>        More: ????????????
>>>>
>>>>    I want to avoid using some of the WTF features of Scala (when a
>>>>        Java programmer looks at the code and says "WTF") in order to
>>>>        ease and accelerate acceptance by Java programmers; as
>>>>        examples, implicits can make code hard to understand and
>>>>        advanced Scala type usages, as James Gosling said, "makes one's
>>>>        head spin".
>>>>
>>>>
>>>> Help and Advice: How should Scala-Wicket be extended and released
>>>>
>>>>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
>>>>        re-write. Given that, what would you do differently in Wicket
>>>>        now that there are years of experience using it?
>>>>
>>>>    How best to get a hosting site, release the code and build a
>>>>        community?
>>>>
>>>>
>>> If you're looking for a place to host it, I'd recommend starting with
>>> Github.  Git is where the crowd is headed, and Github is the easiest
>>> place
>>> to get up and running with it these days.
>>>
>>> You mentioned earlier the idea of it being an Apache project.  If you
>>> wanted
>>> it to be an Apache project, you would start at the Incubator (
>>> http://incubator.apache.org/).  The one barrier you'll have initially is
>>> that Apache favors "community over code"... so it's not a great place to
>>> start a one-man project.  Since this is a port of an existing Apache
>>> project, you might have more leniency, but you'd have to build a
>>> community
>>> around the project before you could ever "graduate" from the incubator.
>>>
>>> Probably Github is your best bet for now.  Build a community.  Then, if
>>> your
>>> community is in favor, move to Apache.  By that time, ASF might have full
>>> git support.
>>>
>>>
>>>     Are there any mechanism to help fund such an open-source project?
>>>>
>>>>
>>> Best bet is to build a community.  Of course, if you can find some
>>> company
>>> that wants such a project, you can get monetary support to develop /
>>> maintain.  But that seems unlikely in this case with the limited number
>>> of
>>> companies looking for Scala out there, and especially since this is an
>>> unproven port of a large Java project.  So, start by getting folks like
>>> jWeekend involved - great coders who are already salivating for Scala.
>>>  Find
>>> other individuals such as yourself who are interested, and build a group
>>> of
>>> core committers.
>>>
>>>
>>>  This is not meant to be a general announcement but rather a means
>>>> for me to get some initial advice as to how to proceed.
>>>>
>>>> Any help is appreciated.
>>>>
>>>> Richard Emberson
>>>>
>>>
>>>
>>> I'm impressed.  Quite an undertaking.
>>>
>>> --
>>> Jeremy Thomerson
>>> http://wickettraining.com
>>> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
>>>
>>>
>>
> --
> Quis custodiet ipsos custodes
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Gerolf Seitz
It's cmd+shift+G (OSX) and it works quite well ;)

On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee <[hidden email]> wrote:

> You can paste a java class into a .scala file and it'll autoconvert.
>  there's a shortcut keystroke, too, but i don't remember what it is.
>
> On Wed, Jan 5, 2011 at 10:40 AM, richard emberson <
> [hidden email]> wrote:
>
> > No IDE, I use Vim. Also, my build environment is Ant-based
> > using scalac and javac.
> >
> > Of course, what I was doing was porting from Java to Scala.
> > To that end I've got some 400 Vim scripts that aid in the
> > port. For instance,
> >
> > :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g
> >
> > converts
> >    final B a[] =
> > to
> >    val a: Array[B] =
> >
> > I don't know if IDEs provide such scripting with regex support.
> > Also, with a simple Vim script and key combination, I can be
> > viewing a ported Scala file and jump to its corresponding source
> > Java Wicket file - very useful when porting or debugging.
> > Yea, IDEs can do stuff me and my Vim scripts can not do, but my
> > fingers know Vim.
> >
> > I also built a JUnit driver class in Scala (and Java) that allowed
> > me to execute a single test method in a given test class by setting
> > two properties in a file that my Ant script reads. This was vital
> > for hunting down bugs.
> >
> > I looked into the tool that allowed Vim to be the front-end and
> > Eclipse to run in server mode which allows a Vim user to access
> > many of the extra features the IDE offers, but, as of a couple of
> > months ago, there was no Scala support in the tool.
> >
> > The father of Scala, Martin Odersky uses Emacs.
> >
> > Richard
> >
> >
> >
> > On 01/05/2011 12:38 AM, Juergen Donnerstag wrote:
> >
> >> Cool. May I ask which tools (IDE) you've been using and what your
> >> experience with these tools has been.
> >>
> >> -Juergen
> >>
> >> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
> >> <[hidden email]>  wrote:
> >>
> >>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<
> >>> [hidden email]
> >>>
> >>>> wrote:
> >>>>
> >>>
> >>>  Dev Wicketers,
> >>>>
> >>>> What: I have ported Wicket to Scala
> >>>>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
> >>>>    This encompasses all of the source and test code. As successive 1.5
> >>>>    snapshots were released, I ported those differences to my Scala
> >>>>    version. I am current with 1.5 M3.
> >>>>
> >>>>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
> >>>>    counting all the println statements I put into the Scala code
> >>>>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
> >>>>    count lines of code.
> >>>>
> >>>>
> >>> I haven't used CLOC before.  I've used Ohcount (
> >>> http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a
> >>> try.
> >>>
> >>>
> >>>   I have also replaced all of the Java collection classes with
> >>>
> >>>>    Scala collection classes (though a small number of Java collection
> >>>>    classes remain that did not have comparable Scala implementations).
> >>>>
> >>>>    I have changed many method return types from the Java returning
> >>>>    some "object" or "null" to Scala returning "Some(object)" or "None"
> >>>>    (using the Scala Option[return-type] construct) - trying to
> >>>>    eliminate nulls.
> >>>>
> >>>>    Lastly, I pushed the IModel[T] typing down to the Component class
> >>>>    making get/set DefaultModel and get/set DefaultModelObject strong
> >>>>    typed.  This included using Scala companion object apply methods
> >>>>    which eliminated having to explicitly declare type parameters in
> >>>>    most end-user code (I had read that one of the objections to
> >>>>    pushing strong typing down to the Component class in Wicket was
> >>>>    that there were "too many notes", end-user code was too verbose).
> >>>>
> >>>>    It can not interoperate with Java Wicket because Scala compiles to
> >>>>    JVM class files and so all of the classes in Java Wicket also
> >>>>    appear in Scala-Wicket.
> >>>>
> >>>
> >>>
> >>>     I have an "internal" name for my Scala port of Wicket which
> >>>>    acknowledges its Wicket heritage as well as advertises its
> >>>>    enterprise level capabilities. For external communications,
> >>>>    I am currently simply call it Scala-Wicket.
> >>>>
> >>>> Why: Scala is a better Java
> >>>>    I was introduced to Scala 9 months ago and quickly determined that
> >>>>    it was a better Java (at least IMO). For Scala to succeed it
> >>>>    requires more programmers to use it. Many on the Scala mailing
> >>>>    lists were from a functional background and seemed not to recognize
> >>>>    that Haskell and Lisp are not blindingly successful but, rather,
> >>>>    niche languages and that the heavy selling of Scala's function and
> >>>>    typing capabilities might turn off Java programmers.
> >>>>
> >>>>    Scala struck me in many ways as a strong-typed JavaScript, at
> >>>>    least, much of the code did not have to have type declarations
> >>>>    because the compiler could infer types in many cases. In addition,
> >>>>    a whole lot of the Java boil-plate code was not needed. As such,
> >>>>    it could be sold as simply a better Java; a more-to-the-point
> >>>>    object oriented language with functional programming in-the-small.
> >>>>
> >>>>    To get more Java programmers to try Scala I looked for a
> >>>>    significant Java application with a strong support and user
> >>>>    community that I could port to Scala. I ended up with Wicket.
> >>>>    Wicket is an enterprise level web framework (unlike existing
> >>>>    Scale web frameworks which place restrictions on enterprise IT
> >>>>    organizations, e.g., by requiring sticky sessions).  It is well
> >>>>    documented. And, as it turned out, very, very importantly it had
> >>>>    a large number of unit tests (the unit tests saved my butt,
> >>>>    without them I would never had succeeded in getting a port that
> >>>>    worked).
> >>>>
> >>>>    No, Really, Why:
> >>>>        I like Scala and I took the time to learn it. Right now about
> >>>>        20% of programmers use Java while only some 0.4% use Scala.
> >>>>        I did not want my effort of learning Scala to be wasted so my
> >>>>        solution is to increase the number of Scala programmers. Where
> >>>>        to get them? Again, my solution is from the existing horde of
> >>>>        Java programmers.
> >>>>
> >>>> Plans: Release, Evolve and Proselytize
> >>>>    I would like to release Scala-Wicket.
> >>>>    I do not know if Apache hosts anything other than Java code.
> >>>>    Growing a community is important.
> >>>>
> >>>>    Still Todo:
> >>>>        Comments: All of the existing class and inline comments are
> >>>>            still Java related.  This would have to be a long, on-going
> >>>>            task to edit the comments so they reflect the code's
> >>>>            Scala usage.
> >>>>        Package path: The code still uses the "org.apache.wicket"
> >>>>            package path and this must be changed - unless this became
> >>>>            an Apache project.
> >>>>        Author: I have quite literally looked at and touched every line
> >>>>            of code but I have not yet felt comfortable with adding
> >>>>            myself as an author since, well, many changes were
> >>>>            syntactic and not semantic.
> >>>>        Refactor with Traits: Currently the port uses Scala traits like
> >>>>            Java interfaces but it should be possible to factor the
> >>>>            common code out into the traits. This would result in many
> >>>>            of the interfaces, the "I" files, such as IModel.scala,
> >>>>            going away.
> >>>>        Some general refactoring:
> >>>>            As an example, consider factoring out the IModel[T] from
> >>>>            Component. Half the time a user wants a Component with
> >>>>            no model, so, if there was a HasModel trait:
> >>>>                class Model[T](var value: T) {
> >>>>                    def getObject: T = value
> >>>>                    def setObject(value: T): Unit = this.value = value
> >>>>                }
> >>>>                trait HasModel[T] {
> >>>>                  var model: Model[T]
> >>>>                  def getDefaultModel: IModel[T] = model
> >>>>                  def setDefaultModel(model: IModel[T]): this.type = {
> >>>>                    ....
> >>>>                    this
> >>>>                  }
> >>>>                  def getDefaultModelObject: Option[T] = {
> >>>>                    ....
> >>>>                  }
> >>>>                  def setDefaultModelObject(obj: T): this.type = {
> >>>>                    ....
> >>>>                    this
> >>>>                  }
> >>>>                }
> >>>>            The Component hierarchy would have no model support.
> >>>>            The user could add model support when needed:
> >>>>                val form = new Form("hi")
> >>>>                  with HasModel[Int] { var model = new Model(42) }
> >>>>            Just an Idea.
> >>>>        STM: There are a number of Scala STM projects and I do not know
> >>>>            if it is useful to add STM capabilities to Scala-Wicket.
> >>>>        RBAC: I've written a Scala implementation of the NIST RBAC
> >>>>            recommended standard and might consider adding it.
> >>>>        Logging: Adding a Scala-based logging framework to aid user
> >>>>            debugging.
> >>>>        Monitoring and stats: In the last couple of years many web
> >>>>            sites have added monitoring and statistics gathering
> >>>>            capabilities (e.g., who clicks what, where, how long, on
> >>>>            what page does the visitor exit the web site, etc.) in
> >>>>            order to know how the web site is being used and then
> >>>>            improve the web site.
> >>>>        Significant Memory Usage Reduction: I've an idea that would
> >>>>            significantly decrease the memory usage of Scala-Wicket and
> >>>>            I plan to do a test implementation.
> >>>>        Replace Java features: There are still some Java-isms that can
> >>>>            be replaced with Scala equivalents.
> >>>>        Port additional Java Wicket libraries to Scala.
> >>>>        Enable multiple instances of a unit tests to be run at once.
> >>>>        More: ????????????
> >>>>
> >>>>    I want to avoid using some of the WTF features of Scala (when a
> >>>>        Java programmer looks at the code and says "WTF") in order to
> >>>>        ease and accelerate acceptance by Java programmers; as
> >>>>        examples, implicits can make code hard to understand and
> >>>>        advanced Scala type usages, as James Gosling said, "makes one's
> >>>>        head spin".
> >>>>
> >>>>
> >>>> Help and Advice: How should Scala-Wicket be extended and released
> >>>>
> >>>>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
> >>>>        re-write. Given that, what would you do differently in Wicket
> >>>>        now that there are years of experience using it?
> >>>>
> >>>>    How best to get a hosting site, release the code and build a
> >>>>        community?
> >>>>
> >>>>
> >>> If you're looking for a place to host it, I'd recommend starting with
> >>> Github.  Git is where the crowd is headed, and Github is the easiest
> >>> place
> >>> to get up and running with it these days.
> >>>
> >>> You mentioned earlier the idea of it being an Apache project.  If you
> >>> wanted
> >>> it to be an Apache project, you would start at the Incubator (
> >>> http://incubator.apache.org/).  The one barrier you'll have initially
> is
> >>> that Apache favors "community over code"... so it's not a great place
> to
> >>> start a one-man project.  Since this is a port of an existing Apache
> >>> project, you might have more leniency, but you'd have to build a
> >>> community
> >>> around the project before you could ever "graduate" from the incubator.
> >>>
> >>> Probably Github is your best bet for now.  Build a community.  Then, if
> >>> your
> >>> community is in favor, move to Apache.  By that time, ASF might have
> full
> >>> git support.
> >>>
> >>>
> >>>     Are there any mechanism to help fund such an open-source project?
> >>>>
> >>>>
> >>> Best bet is to build a community.  Of course, if you can find some
> >>> company
> >>> that wants such a project, you can get monetary support to develop /
> >>> maintain.  But that seems unlikely in this case with the limited number
> >>> of
> >>> companies looking for Scala out there, and especially since this is an
> >>> unproven port of a large Java project.  So, start by getting folks like
> >>> jWeekend involved - great coders who are already salivating for Scala.
> >>>  Find
> >>> other individuals such as yourself who are interested, and build a
> group
> >>> of
> >>> core committers.
> >>>
> >>>
> >>>  This is not meant to be a general announcement but rather a means
> >>>> for me to get some initial advice as to how to proceed.
> >>>>
> >>>> Any help is appreciated.
> >>>>
> >>>> Richard Emberson
> >>>>
> >>>
> >>>
> >>> I'm impressed.  Quite an undertaking.
> >>>
> >>> --
> >>> Jeremy Thomerson
> >>> http://wickettraining.com
> >>> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
> >>>
> >>>
> >>
> > --
> > Quis custodiet ipsos custodes
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

James Carman
Is this in IntelliJ IDEA?

On Wed, Jan 5, 2011 at 6:04 PM, Gerolf Seitz <[hidden email]> wrote:

> It's cmd+shift+G (OSX) and it works quite well ;)
>
> On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee <[hidden email]> wrote:
>
>> You can paste a java class into a .scala file and it'll autoconvert.
>>  there's a shortcut keystroke, too, but i don't remember what it is.
>>
>> On Wed, Jan 5, 2011 at 10:40 AM, richard emberson <
>> [hidden email]> wrote:
>>
>> > No IDE, I use Vim. Also, my build environment is Ant-based
>> > using scalac and javac.
>> >
>> > Of course, what I was doing was porting from Java to Scala.
>> > To that end I've got some 400 Vim scripts that aid in the
>> > port. For instance,
>> >
>> > :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g
>> >
>> > converts
>> >    final B a[] =
>> > to
>> >    val a: Array[B] =
>> >
>> > I don't know if IDEs provide such scripting with regex support.
>> > Also, with a simple Vim script and key combination, I can be
>> > viewing a ported Scala file and jump to its corresponding source
>> > Java Wicket file - very useful when porting or debugging.
>> > Yea, IDEs can do stuff me and my Vim scripts can not do, but my
>> > fingers know Vim.
>> >
>> > I also built a JUnit driver class in Scala (and Java) that allowed
>> > me to execute a single test method in a given test class by setting
>> > two properties in a file that my Ant script reads. This was vital
>> > for hunting down bugs.
>> >
>> > I looked into the tool that allowed Vim to be the front-end and
>> > Eclipse to run in server mode which allows a Vim user to access
>> > many of the extra features the IDE offers, but, as of a couple of
>> > months ago, there was no Scala support in the tool.
>> >
>> > The father of Scala, Martin Odersky uses Emacs.
>> >
>> > Richard
>> >
>> >
>> >
>> > On 01/05/2011 12:38 AM, Juergen Donnerstag wrote:
>> >
>> >> Cool. May I ask which tools (IDE) you've been using and what your
>> >> experience with these tools has been.
>> >>
>> >> -Juergen
>> >>
>> >> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
>> >> <[hidden email]>  wrote:
>> >>
>> >>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<
>> >>> [hidden email]
>> >>>
>> >>>> wrote:
>> >>>>
>> >>>
>> >>>  Dev Wicketers,
>> >>>>
>> >>>> What: I have ported Wicket to Scala
>> >>>>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
>> >>>>    This encompasses all of the source and test code. As successive 1.5
>> >>>>    snapshots were released, I ported those differences to my Scala
>> >>>>    version. I am current with 1.5 M3.
>> >>>>
>> >>>>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>> >>>>    counting all the println statements I put into the Scala code
>> >>>>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
>> >>>>    count lines of code.
>> >>>>
>> >>>>
>> >>> I haven't used CLOC before.  I've used Ohcount (
>> >>> http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a
>> >>> try.
>> >>>
>> >>>
>> >>>   I have also replaced all of the Java collection classes with
>> >>>
>> >>>>    Scala collection classes (though a small number of Java collection
>> >>>>    classes remain that did not have comparable Scala implementations).
>> >>>>
>> >>>>    I have changed many method return types from the Java returning
>> >>>>    some "object" or "null" to Scala returning "Some(object)" or "None"
>> >>>>    (using the Scala Option[return-type] construct) - trying to
>> >>>>    eliminate nulls.
>> >>>>
>> >>>>    Lastly, I pushed the IModel[T] typing down to the Component class
>> >>>>    making get/set DefaultModel and get/set DefaultModelObject strong
>> >>>>    typed.  This included using Scala companion object apply methods
>> >>>>    which eliminated having to explicitly declare type parameters in
>> >>>>    most end-user code (I had read that one of the objections to
>> >>>>    pushing strong typing down to the Component class in Wicket was
>> >>>>    that there were "too many notes", end-user code was too verbose).
>> >>>>
>> >>>>    It can not interoperate with Java Wicket because Scala compiles to
>> >>>>    JVM class files and so all of the classes in Java Wicket also
>> >>>>    appear in Scala-Wicket.
>> >>>>
>> >>>
>> >>>
>> >>>     I have an "internal" name for my Scala port of Wicket which
>> >>>>    acknowledges its Wicket heritage as well as advertises its
>> >>>>    enterprise level capabilities. For external communications,
>> >>>>    I am currently simply call it Scala-Wicket.
>> >>>>
>> >>>> Why: Scala is a better Java
>> >>>>    I was introduced to Scala 9 months ago and quickly determined that
>> >>>>    it was a better Java (at least IMO). For Scala to succeed it
>> >>>>    requires more programmers to use it. Many on the Scala mailing
>> >>>>    lists were from a functional background and seemed not to recognize
>> >>>>    that Haskell and Lisp are not blindingly successful but, rather,
>> >>>>    niche languages and that the heavy selling of Scala's function and
>> >>>>    typing capabilities might turn off Java programmers.
>> >>>>
>> >>>>    Scala struck me in many ways as a strong-typed JavaScript, at
>> >>>>    least, much of the code did not have to have type declarations
>> >>>>    because the compiler could infer types in many cases. In addition,
>> >>>>    a whole lot of the Java boil-plate code was not needed. As such,
>> >>>>    it could be sold as simply a better Java; a more-to-the-point
>> >>>>    object oriented language with functional programming in-the-small.
>> >>>>
>> >>>>    To get more Java programmers to try Scala I looked for a
>> >>>>    significant Java application with a strong support and user
>> >>>>    community that I could port to Scala. I ended up with Wicket.
>> >>>>    Wicket is an enterprise level web framework (unlike existing
>> >>>>    Scale web frameworks which place restrictions on enterprise IT
>> >>>>    organizations, e.g., by requiring sticky sessions).  It is well
>> >>>>    documented. And, as it turned out, very, very importantly it had
>> >>>>    a large number of unit tests (the unit tests saved my butt,
>> >>>>    without them I would never had succeeded in getting a port that
>> >>>>    worked).
>> >>>>
>> >>>>    No, Really, Why:
>> >>>>        I like Scala and I took the time to learn it. Right now about
>> >>>>        20% of programmers use Java while only some 0.4% use Scala.
>> >>>>        I did not want my effort of learning Scala to be wasted so my
>> >>>>        solution is to increase the number of Scala programmers. Where
>> >>>>        to get them? Again, my solution is from the existing horde of
>> >>>>        Java programmers.
>> >>>>
>> >>>> Plans: Release, Evolve and Proselytize
>> >>>>    I would like to release Scala-Wicket.
>> >>>>    I do not know if Apache hosts anything other than Java code.
>> >>>>    Growing a community is important.
>> >>>>
>> >>>>    Still Todo:
>> >>>>        Comments: All of the existing class and inline comments are
>> >>>>            still Java related.  This would have to be a long, on-going
>> >>>>            task to edit the comments so they reflect the code's
>> >>>>            Scala usage.
>> >>>>        Package path: The code still uses the "org.apache.wicket"
>> >>>>            package path and this must be changed - unless this became
>> >>>>            an Apache project.
>> >>>>        Author: I have quite literally looked at and touched every line
>> >>>>            of code but I have not yet felt comfortable with adding
>> >>>>            myself as an author since, well, many changes were
>> >>>>            syntactic and not semantic.
>> >>>>        Refactor with Traits: Currently the port uses Scala traits like
>> >>>>            Java interfaces but it should be possible to factor the
>> >>>>            common code out into the traits. This would result in many
>> >>>>            of the interfaces, the "I" files, such as IModel.scala,
>> >>>>            going away.
>> >>>>        Some general refactoring:
>> >>>>            As an example, consider factoring out the IModel[T] from
>> >>>>            Component. Half the time a user wants a Component with
>> >>>>            no model, so, if there was a HasModel trait:
>> >>>>                class Model[T](var value: T) {
>> >>>>                    def getObject: T = value
>> >>>>                    def setObject(value: T): Unit = this.value = value
>> >>>>                }
>> >>>>                trait HasModel[T] {
>> >>>>                  var model: Model[T]
>> >>>>                  def getDefaultModel: IModel[T] = model
>> >>>>                  def setDefaultModel(model: IModel[T]): this.type = {
>> >>>>                    ....
>> >>>>                    this
>> >>>>                  }
>> >>>>                  def getDefaultModelObject: Option[T] = {
>> >>>>                    ....
>> >>>>                  }
>> >>>>                  def setDefaultModelObject(obj: T): this.type = {
>> >>>>                    ....
>> >>>>                    this
>> >>>>                  }
>> >>>>                }
>> >>>>            The Component hierarchy would have no model support.
>> >>>>            The user could add model support when needed:
>> >>>>                val form = new Form("hi")
>> >>>>                  with HasModel[Int] { var model = new Model(42) }
>> >>>>            Just an Idea.
>> >>>>        STM: There are a number of Scala STM projects and I do not know
>> >>>>            if it is useful to add STM capabilities to Scala-Wicket.
>> >>>>        RBAC: I've written a Scala implementation of the NIST RBAC
>> >>>>            recommended standard and might consider adding it.
>> >>>>        Logging: Adding a Scala-based logging framework to aid user
>> >>>>            debugging.
>> >>>>        Monitoring and stats: In the last couple of years many web
>> >>>>            sites have added monitoring and statistics gathering
>> >>>>            capabilities (e.g., who clicks what, where, how long, on
>> >>>>            what page does the visitor exit the web site, etc.) in
>> >>>>            order to know how the web site is being used and then
>> >>>>            improve the web site.
>> >>>>        Significant Memory Usage Reduction: I've an idea that would
>> >>>>            significantly decrease the memory usage of Scala-Wicket and
>> >>>>            I plan to do a test implementation.
>> >>>>        Replace Java features: There are still some Java-isms that can
>> >>>>            be replaced with Scala equivalents.
>> >>>>        Port additional Java Wicket libraries to Scala.
>> >>>>        Enable multiple instances of a unit tests to be run at once.
>> >>>>        More: ????????????
>> >>>>
>> >>>>    I want to avoid using some of the WTF features of Scala (when a
>> >>>>        Java programmer looks at the code and says "WTF") in order to
>> >>>>        ease and accelerate acceptance by Java programmers; as
>> >>>>        examples, implicits can make code hard to understand and
>> >>>>        advanced Scala type usages, as James Gosling said, "makes one's
>> >>>>        head spin".
>> >>>>
>> >>>>
>> >>>> Help and Advice: How should Scala-Wicket be extended and released
>> >>>>
>> >>>>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
>> >>>>        re-write. Given that, what would you do differently in Wicket
>> >>>>        now that there are years of experience using it?
>> >>>>
>> >>>>    How best to get a hosting site, release the code and build a
>> >>>>        community?
>> >>>>
>> >>>>
>> >>> If you're looking for a place to host it, I'd recommend starting with
>> >>> Github.  Git is where the crowd is headed, and Github is the easiest
>> >>> place
>> >>> to get up and running with it these days.
>> >>>
>> >>> You mentioned earlier the idea of it being an Apache project.  If you
>> >>> wanted
>> >>> it to be an Apache project, you would start at the Incubator (
>> >>> http://incubator.apache.org/).  The one barrier you'll have initially
>> is
>> >>> that Apache favors "community over code"... so it's not a great place
>> to
>> >>> start a one-man project.  Since this is a port of an existing Apache
>> >>> project, you might have more leniency, but you'd have to build a
>> >>> community
>> >>> around the project before you could ever "graduate" from the incubator.
>> >>>
>> >>> Probably Github is your best bet for now.  Build a community.  Then, if
>> >>> your
>> >>> community is in favor, move to Apache.  By that time, ASF might have
>> full
>> >>> git support.
>> >>>
>> >>>
>> >>>     Are there any mechanism to help fund such an open-source project?
>> >>>>
>> >>>>
>> >>> Best bet is to build a community.  Of course, if you can find some
>> >>> company
>> >>> that wants such a project, you can get monetary support to develop /
>> >>> maintain.  But that seems unlikely in this case with the limited number
>> >>> of
>> >>> companies looking for Scala out there, and especially since this is an
>> >>> unproven port of a large Java project.  So, start by getting folks like
>> >>> jWeekend involved - great coders who are already salivating for Scala.
>> >>>  Find
>> >>> other individuals such as yourself who are interested, and build a
>> group
>> >>> of
>> >>> core committers.
>> >>>
>> >>>
>> >>>  This is not meant to be a general announcement but rather a means
>> >>>> for me to get some initial advice as to how to proceed.
>> >>>>
>> >>>> Any help is appreciated.
>> >>>>
>> >>>> Richard Emberson
>> >>>>
>> >>>
>> >>>
>> >>> I'm impressed.  Quite an undertaking.
>> >>>
>> >>> --
>> >>> Jeremy Thomerson
>> >>> http://wickettraining.com
>> >>> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
>> >>>
>> >>>
>> >>
>> > --
>> > Quis custodiet ipsos custodes
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Gerolf Seitz
>
> Is this in IntelliJ IDEA?
>
>
yes


> On Wed, Jan 5, 2011 at 6:04 PM, Gerolf Seitz <[hidden email]>
> wrote:
> > It's cmd+shift+G (OSX) and it works quite well ;)
> >
> > On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee <[hidden email]>
> wrote:
> >
> >> You can paste a java class into a .scala file and it'll autoconvert.
> >>  there's a shortcut keystroke, too, but i don't remember what it is.
> >>
> >> On Wed, Jan 5, 2011 at 10:40 AM, richard emberson <
> >> [hidden email]> wrote:
> >>
> >> > No IDE, I use Vim. Also, my build environment is Ant-based
> >> > using scalac and javac.
> >> >
> >> > Of course, what I was doing was porting from Java to Scala.
> >> > To that end I've got some 400 Vim scripts that aid in the
> >> > port. For instance,
> >> >
> >> > :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1]
> =/g
> >> >
> >> > converts
> >> >    final B a[] =
> >> > to
> >> >    val a: Array[B] =
> >> >
> >> > I don't know if IDEs provide such scripting with regex support.
> >> > Also, with a simple Vim script and key combination, I can be
> >> > viewing a ported Scala file and jump to its corresponding source
> >> > Java Wicket file - very useful when porting or debugging.
> >> > Yea, IDEs can do stuff me and my Vim scripts can not do, but my
> >> > fingers know Vim.
> >> >
> >> > I also built a JUnit driver class in Scala (and Java) that allowed
> >> > me to execute a single test method in a given test class by setting
> >> > two properties in a file that my Ant script reads. This was vital
> >> > for hunting down bugs.
> >> >
> >> > I looked into the tool that allowed Vim to be the front-end and
> >> > Eclipse to run in server mode which allows a Vim user to access
> >> > many of the extra features the IDE offers, but, as of a couple of
> >> > months ago, there was no Scala support in the tool.
> >> >
> >> > The father of Scala, Martin Odersky uses Emacs.
> >> >
> >> > Richard
> >> >
> >> >
> >> >
> >> > On 01/05/2011 12:38 AM, Juergen Donnerstag wrote:
> >> >
> >> >> Cool. May I ask which tools (IDE) you've been using and what your
> >> >> experience with these tools has been.
> >> >>
> >> >> -Juergen
> >> >>
> >> >> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
> >> >> <[hidden email]>  wrote:
> >> >>
> >> >>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<
> >> >>> [hidden email]
> >> >>>
> >> >>>> wrote:
> >> >>>>
> >> >>>
> >> >>>  Dev Wicketers,
> >> >>>>
> >> >>>> What: I have ported Wicket to Scala
> >> >>>>    A couple of months ago I took a 1.5 snapshot and ported to
> Scala.
> >> >>>>    This encompasses all of the source and test code. As successive
> 1.5
> >> >>>>    snapshots were released, I ported those differences to my Scala
> >> >>>>    version. I am current with 1.5 M3.
> >> >>>>
> >> >>>>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
> >> >>>>    counting all the println statements I put into the Scala code
> >> >>>>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
> >> >>>>    count lines of code.
> >> >>>>
> >> >>>>
> >> >>> I haven't used CLOC before.  I've used Ohcount (
> >> >>> http://www.ohloh.net/p/ohcount) and like it.  I'll have to give
> this a
> >> >>> try.
> >> >>>
> >> >>>
> >> >>>   I have also replaced all of the Java collection classes with
> >> >>>
> >> >>>>    Scala collection classes (though a small number of Java
> collection
> >> >>>>    classes remain that did not have comparable Scala
> implementations).
> >> >>>>
> >> >>>>    I have changed many method return types from the Java returning
> >> >>>>    some "object" or "null" to Scala returning "Some(object)" or
> "None"
> >> >>>>    (using the Scala Option[return-type] construct) - trying to
> >> >>>>    eliminate nulls.
> >> >>>>
> >> >>>>    Lastly, I pushed the IModel[T] typing down to the Component
> class
> >> >>>>    making get/set DefaultModel and get/set DefaultModelObject
> strong
> >> >>>>    typed.  This included using Scala companion object apply methods
> >> >>>>    which eliminated having to explicitly declare type parameters in
> >> >>>>    most end-user code (I had read that one of the objections to
> >> >>>>    pushing strong typing down to the Component class in Wicket was
> >> >>>>    that there were "too many notes", end-user code was too
> verbose).
> >> >>>>
> >> >>>>    It can not interoperate with Java Wicket because Scala compiles
> to
> >> >>>>    JVM class files and so all of the classes in Java Wicket also
> >> >>>>    appear in Scala-Wicket.
> >> >>>>
> >> >>>
> >> >>>
> >> >>>     I have an "internal" name for my Scala port of Wicket which
> >> >>>>    acknowledges its Wicket heritage as well as advertises its
> >> >>>>    enterprise level capabilities. For external communications,
> >> >>>>    I am currently simply call it Scala-Wicket.
> >> >>>>
> >> >>>> Why: Scala is a better Java
> >> >>>>    I was introduced to Scala 9 months ago and quickly determined
> that
> >> >>>>    it was a better Java (at least IMO). For Scala to succeed it
> >> >>>>    requires more programmers to use it. Many on the Scala mailing
> >> >>>>    lists were from a functional background and seemed not to
> recognize
> >> >>>>    that Haskell and Lisp are not blindingly successful but, rather,
> >> >>>>    niche languages and that the heavy selling of Scala's function
> and
> >> >>>>    typing capabilities might turn off Java programmers.
> >> >>>>
> >> >>>>    Scala struck me in many ways as a strong-typed JavaScript, at
> >> >>>>    least, much of the code did not have to have type declarations
> >> >>>>    because the compiler could infer types in many cases. In
> addition,
> >> >>>>    a whole lot of the Java boil-plate code was not needed. As such,
> >> >>>>    it could be sold as simply a better Java; a more-to-the-point
> >> >>>>    object oriented language with functional programming
> in-the-small.
> >> >>>>
> >> >>>>    To get more Java programmers to try Scala I looked for a
> >> >>>>    significant Java application with a strong support and user
> >> >>>>    community that I could port to Scala. I ended up with Wicket.
> >> >>>>    Wicket is an enterprise level web framework (unlike existing
> >> >>>>    Scale web frameworks which place restrictions on enterprise IT
> >> >>>>    organizations, e.g., by requiring sticky sessions).  It is well
> >> >>>>    documented. And, as it turned out, very, very importantly it had
> >> >>>>    a large number of unit tests (the unit tests saved my butt,
> >> >>>>    without them I would never had succeeded in getting a port that
> >> >>>>    worked).
> >> >>>>
> >> >>>>    No, Really, Why:
> >> >>>>        I like Scala and I took the time to learn it. Right now
> about
> >> >>>>        20% of programmers use Java while only some 0.4% use Scala.
> >> >>>>        I did not want my effort of learning Scala to be wasted so
> my
> >> >>>>        solution is to increase the number of Scala programmers.
> Where
> >> >>>>        to get them? Again, my solution is from the existing horde
> of
> >> >>>>        Java programmers.
> >> >>>>
> >> >>>> Plans: Release, Evolve and Proselytize
> >> >>>>    I would like to release Scala-Wicket.
> >> >>>>    I do not know if Apache hosts anything other than Java code.
> >> >>>>    Growing a community is important.
> >> >>>>
> >> >>>>    Still Todo:
> >> >>>>        Comments: All of the existing class and inline comments are
> >> >>>>            still Java related.  This would have to be a long,
> on-going
> >> >>>>            task to edit the comments so they reflect the code's
> >> >>>>            Scala usage.
> >> >>>>        Package path: The code still uses the "org.apache.wicket"
> >> >>>>            package path and this must be changed - unless this
> became
> >> >>>>            an Apache project.
> >> >>>>        Author: I have quite literally looked at and touched every
> line
> >> >>>>            of code but I have not yet felt comfortable with adding
> >> >>>>            myself as an author since, well, many changes were
> >> >>>>            syntactic and not semantic.
> >> >>>>        Refactor with Traits: Currently the port uses Scala traits
> like
> >> >>>>            Java interfaces but it should be possible to factor the
> >> >>>>            common code out into the traits. This would result in
> many
> >> >>>>            of the interfaces, the "I" files, such as IModel.scala,
> >> >>>>            going away.
> >> >>>>        Some general refactoring:
> >> >>>>            As an example, consider factoring out the IModel[T] from
> >> >>>>            Component. Half the time a user wants a Component with
> >> >>>>            no model, so, if there was a HasModel trait:
> >> >>>>                class Model[T](var value: T) {
> >> >>>>                    def getObject: T = value
> >> >>>>                    def setObject(value: T): Unit = this.value =
> value
> >> >>>>                }
> >> >>>>                trait HasModel[T] {
> >> >>>>                  var model: Model[T]
> >> >>>>                  def getDefaultModel: IModel[T] = model
> >> >>>>                  def setDefaultModel(model: IModel[T]): this.type =
> {
> >> >>>>                    ....
> >> >>>>                    this
> >> >>>>                  }
> >> >>>>                  def getDefaultModelObject: Option[T] = {
> >> >>>>                    ....
> >> >>>>                  }
> >> >>>>                  def setDefaultModelObject(obj: T): this.type = {
> >> >>>>                    ....
> >> >>>>                    this
> >> >>>>                  }
> >> >>>>                }
> >> >>>>            The Component hierarchy would have no model support.
> >> >>>>            The user could add model support when needed:
> >> >>>>                val form = new Form("hi")
> >> >>>>                  with HasModel[Int] { var model = new Model(42) }
> >> >>>>            Just an Idea.
> >> >>>>        STM: There are a number of Scala STM projects and I do not
> know
> >> >>>>            if it is useful to add STM capabilities to Scala-Wicket.
> >> >>>>        RBAC: I've written a Scala implementation of the NIST RBAC
> >> >>>>            recommended standard and might consider adding it.
> >> >>>>        Logging: Adding a Scala-based logging framework to aid user
> >> >>>>            debugging.
> >> >>>>        Monitoring and stats: In the last couple of years many web
> >> >>>>            sites have added monitoring and statistics gathering
> >> >>>>            capabilities (e.g., who clicks what, where, how long, on
> >> >>>>            what page does the visitor exit the web site, etc.) in
> >> >>>>            order to know how the web site is being used and then
> >> >>>>            improve the web site.
> >> >>>>        Significant Memory Usage Reduction: I've an idea that would
> >> >>>>            significantly decrease the memory usage of Scala-Wicket
> and
> >> >>>>            I plan to do a test implementation.
> >> >>>>        Replace Java features: There are still some Java-isms that
> can
> >> >>>>            be replaced with Scala equivalents.
> >> >>>>        Port additional Java Wicket libraries to Scala.
> >> >>>>        Enable multiple instances of a unit tests to be run at once.
> >> >>>>        More: ????????????
> >> >>>>
> >> >>>>    I want to avoid using some of the WTF features of Scala (when a
> >> >>>>        Java programmer looks at the code and says "WTF") in order
> to
> >> >>>>        ease and accelerate acceptance by Java programmers; as
> >> >>>>        examples, implicits can make code hard to understand and
> >> >>>>        advanced Scala type usages, as James Gosling said, "makes
> one's
> >> >>>>        head spin".
> >> >>>>
> >> >>>>
> >> >>>> Help and Advice: How should Scala-Wicket be extended and released
> >> >>>>
> >> >>>>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
> >> >>>>        re-write. Given that, what would you do differently in
> Wicket
> >> >>>>        now that there are years of experience using it?
> >> >>>>
> >> >>>>    How best to get a hosting site, release the code and build a
> >> >>>>        community?
> >> >>>>
> >> >>>>
> >> >>> If you're looking for a place to host it, I'd recommend starting
> with
> >> >>> Github.  Git is where the crowd is headed, and Github is the easiest
> >> >>> place
> >> >>> to get up and running with it these days.
> >> >>>
> >> >>> You mentioned earlier the idea of it being an Apache project.  If
> you
> >> >>> wanted
> >> >>> it to be an Apache project, you would start at the Incubator (
> >> >>> http://incubator.apache.org/).  The one barrier you'll have
> initially
> >> is
> >> >>> that Apache favors "community over code"... so it's not a great
> place
> >> to
> >> >>> start a one-man project.  Since this is a port of an existing Apache
> >> >>> project, you might have more leniency, but you'd have to build a
> >> >>> community
> >> >>> around the project before you could ever "graduate" from the
> incubator.
> >> >>>
> >> >>> Probably Github is your best bet for now.  Build a community.  Then,
> if
> >> >>> your
> >> >>> community is in favor, move to Apache.  By that time, ASF might have
> >> full
> >> >>> git support.
> >> >>>
> >> >>>
> >> >>>     Are there any mechanism to help fund such an open-source
> project?
> >> >>>>
> >> >>>>
> >> >>> Best bet is to build a community.  Of course, if you can find some
> >> >>> company
> >> >>> that wants such a project, you can get monetary support to develop /
> >> >>> maintain.  But that seems unlikely in this case with the limited
> number
> >> >>> of
> >> >>> companies looking for Scala out there, and especially since this is
> an
> >> >>> unproven port of a large Java project.  So, start by getting folks
> like
> >> >>> jWeekend involved - great coders who are already salivating for
> Scala.
> >> >>>  Find
> >> >>> other individuals such as yourself who are interested, and build a
> >> group
> >> >>> of
> >> >>> core committers.
> >> >>>
> >> >>>
> >> >>>  This is not meant to be a general announcement but rather a means
> >> >>>> for me to get some initial advice as to how to proceed.
> >> >>>>
> >> >>>> Any help is appreciated.
> >> >>>>
> >> >>>> Richard Emberson
> >> >>>>
> >> >>>
> >> >>>
> >> >>> I'm impressed.  Quite an undertaking.
> >> >>>
> >> >>> --
> >> >>> Jeremy Thomerson
> >> >>> http://wickettraining.com
> >> >>> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
> >> >>>
> >> >>>
> >> >>
> >> > --
> >> > Quis custodiet ipsos custodes
> >> >
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

richard emberson
In reply to this post by Gerolf Seitz
So there is an IDE that you can point at a directory tree and
tell it to convert all of the Java files to Scala files.
Does it do a 100% conversion, 90%, 50% or 10% (on average)?
Do you have a link to a page documenting this feature?

Thanks
Richard

On 01/05/2011 03:04 PM, Gerolf Seitz wrote:

> It's cmd+shift+G (OSX) and it works quite well ;)
>
> On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee<[hidden email]>  wrote:
>
>> You can paste a java class into a .scala file and it'll autoconvert.
>>   there's a shortcut keystroke, too, but i don't remember what it is.
>>
>> On Wed, Jan 5, 2011 at 10:40 AM, richard emberson<
>> [hidden email]>  wrote:
>>
>>> No IDE, I use Vim. Also, my build environment is Ant-based
>>> using scalac and javac.
>>>
>>> Of course, what I was doing was porting from Java to Scala.
>>> To that end I've got some 400 Vim scripts that aid in the
>>> port. For instance,
>>>
>>> :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g
>>>
>>> converts
>>>     final B a[] =
>>> to
>>>     val a: Array[B] =
>>>
>>> I don't know if IDEs provide such scripting with regex support.
>>> Also, with a simple Vim script and key combination, I can be
>>> viewing a ported Scala file and jump to its corresponding source
>>> Java Wicket file - very useful when porting or debugging.
>>> Yea, IDEs can do stuff me and my Vim scripts can not do, but my
>>> fingers know Vim.
>>>
>>> I also built a JUnit driver class in Scala (and Java) that allowed
>>> me to execute a single test method in a given test class by setting
>>> two properties in a file that my Ant script reads. This was vital
>>> for hunting down bugs.
>>>
>>> I looked into the tool that allowed Vim to be the front-end and
>>> Eclipse to run in server mode which allows a Vim user to access
>>> many of the extra features the IDE offers, but, as of a couple of
>>> months ago, there was no Scala support in the tool.
>>>
>>> The father of Scala, Martin Odersky uses Emacs.
>>>
>>> Richard
>>>
>>>
>>>
>>> On 01/05/2011 12:38 AM, Juergen Donnerstag wrote:
>>>
>>>> Cool. May I ask which tools (IDE) you've been using and what your
>>>> experience with these tools has been.
>>>>
>>>> -Juergen
>>>>
>>>> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
>>>> <[hidden email]>   wrote:
>>>>
>>>>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<
>>>>> [hidden email]
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>
>>>>>   Dev Wicketers,
>>>>>>
>>>>>> What: I have ported Wicket to Scala
>>>>>>     A couple of months ago I took a 1.5 snapshot and ported to Scala.
>>>>>>     This encompasses all of the source and test code. As successive 1.5
>>>>>>     snapshots were released, I ported those differences to my Scala
>>>>>>     version. I am current with 1.5 M3.
>>>>>>
>>>>>>     The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>>>>>>     counting all the println statements I put into the Scala code
>>>>>>     for debugging). I used cloc (http://cloc.sourceforge.net/) to
>>>>>>     count lines of code.
>>>>>>
>>>>>>
>>>>> I haven't used CLOC before.  I've used Ohcount (
>>>>> http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a
>>>>> try.
>>>>>
>>>>>
>>>>>    I have also replaced all of the Java collection classes with
>>>>>
>>>>>>     Scala collection classes (though a small number of Java collection
>>>>>>     classes remain that did not have comparable Scala implementations).
>>>>>>
>>>>>>     I have changed many method return types from the Java returning
>>>>>>     some "object" or "null" to Scala returning "Some(object)" or "None"
>>>>>>     (using the Scala Option[return-type] construct) - trying to
>>>>>>     eliminate nulls.
>>>>>>
>>>>>>     Lastly, I pushed the IModel[T] typing down to the Component class
>>>>>>     making get/set DefaultModel and get/set DefaultModelObject strong
>>>>>>     typed.  This included using Scala companion object apply methods
>>>>>>     which eliminated having to explicitly declare type parameters in
>>>>>>     most end-user code (I had read that one of the objections to
>>>>>>     pushing strong typing down to the Component class in Wicket was
>>>>>>     that there were "too many notes", end-user code was too verbose).
>>>>>>
>>>>>>     It can not interoperate with Java Wicket because Scala compiles to
>>>>>>     JVM class files and so all of the classes in Java Wicket also
>>>>>>     appear in Scala-Wicket.
>>>>>>
>>>>>
>>>>>
>>>>>      I have an "internal" name for my Scala port of Wicket which
>>>>>>     acknowledges its Wicket heritage as well as advertises its
>>>>>>     enterprise level capabilities. For external communications,
>>>>>>     I am currently simply call it Scala-Wicket.
>>>>>>
>>>>>> Why: Scala is a better Java
>>>>>>     I was introduced to Scala 9 months ago and quickly determined that
>>>>>>     it was a better Java (at least IMO). For Scala to succeed it
>>>>>>     requires more programmers to use it. Many on the Scala mailing
>>>>>>     lists were from a functional background and seemed not to recognize
>>>>>>     that Haskell and Lisp are not blindingly successful but, rather,
>>>>>>     niche languages and that the heavy selling of Scala's function and
>>>>>>     typing capabilities might turn off Java programmers.
>>>>>>
>>>>>>     Scala struck me in many ways as a strong-typed JavaScript, at
>>>>>>     least, much of the code did not have to have type declarations
>>>>>>     because the compiler could infer types in many cases. In addition,
>>>>>>     a whole lot of the Java boil-plate code was not needed. As such,
>>>>>>     it could be sold as simply a better Java; a more-to-the-point
>>>>>>     object oriented language with functional programming in-the-small.
>>>>>>
>>>>>>     To get more Java programmers to try Scala I looked for a
>>>>>>     significant Java application with a strong support and user
>>>>>>     community that I could port to Scala. I ended up with Wicket.
>>>>>>     Wicket is an enterprise level web framework (unlike existing
>>>>>>     Scale web frameworks which place restrictions on enterprise IT
>>>>>>     organizations, e.g., by requiring sticky sessions).  It is well
>>>>>>     documented. And, as it turned out, very, very importantly it had
>>>>>>     a large number of unit tests (the unit tests saved my butt,
>>>>>>     without them I would never had succeeded in getting a port that
>>>>>>     worked).
>>>>>>
>>>>>>     No, Really, Why:
>>>>>>         I like Scala and I took the time to learn it. Right now about
>>>>>>         20% of programmers use Java while only some 0.4% use Scala.
>>>>>>         I did not want my effort of learning Scala to be wasted so my
>>>>>>         solution is to increase the number of Scala programmers. Where
>>>>>>         to get them? Again, my solution is from the existing horde of
>>>>>>         Java programmers.
>>>>>>
>>>>>> Plans: Release, Evolve and Proselytize
>>>>>>     I would like to release Scala-Wicket.
>>>>>>     I do not know if Apache hosts anything other than Java code.
>>>>>>     Growing a community is important.
>>>>>>
>>>>>>     Still Todo:
>>>>>>         Comments: All of the existing class and inline comments are
>>>>>>             still Java related.  This would have to be a long, on-going
>>>>>>             task to edit the comments so they reflect the code's
>>>>>>             Scala usage.
>>>>>>         Package path: The code still uses the "org.apache.wicket"
>>>>>>             package path and this must be changed - unless this became
>>>>>>             an Apache project.
>>>>>>         Author: I have quite literally looked at and touched every line
>>>>>>             of code but I have not yet felt comfortable with adding
>>>>>>             myself as an author since, well, many changes were
>>>>>>             syntactic and not semantic.
>>>>>>         Refactor with Traits: Currently the port uses Scala traits like
>>>>>>             Java interfaces but it should be possible to factor the
>>>>>>             common code out into the traits. This would result in many
>>>>>>             of the interfaces, the "I" files, such as IModel.scala,
>>>>>>             going away.
>>>>>>         Some general refactoring:
>>>>>>             As an example, consider factoring out the IModel[T] from
>>>>>>             Component. Half the time a user wants a Component with
>>>>>>             no model, so, if there was a HasModel trait:
>>>>>>                 class Model[T](var value: T) {
>>>>>>                     def getObject: T = value
>>>>>>                     def setObject(value: T): Unit = this.value = value
>>>>>>                 }
>>>>>>                 trait HasModel[T] {
>>>>>>                   var model: Model[T]
>>>>>>                   def getDefaultModel: IModel[T] = model
>>>>>>                   def setDefaultModel(model: IModel[T]): this.type = {
>>>>>>                     ....
>>>>>>                     this
>>>>>>                   }
>>>>>>                   def getDefaultModelObject: Option[T] = {
>>>>>>                     ....
>>>>>>                   }
>>>>>>                   def setDefaultModelObject(obj: T): this.type = {
>>>>>>                     ....
>>>>>>                     this
>>>>>>                   }
>>>>>>                 }
>>>>>>             The Component hierarchy would have no model support.
>>>>>>             The user could add model support when needed:
>>>>>>                 val form = new Form("hi")
>>>>>>                   with HasModel[Int] { var model = new Model(42) }
>>>>>>             Just an Idea.
>>>>>>         STM: There are a number of Scala STM projects and I do not know
>>>>>>             if it is useful to add STM capabilities to Scala-Wicket.
>>>>>>         RBAC: I've written a Scala implementation of the NIST RBAC
>>>>>>             recommended standard and might consider adding it.
>>>>>>         Logging: Adding a Scala-based logging framework to aid user
>>>>>>             debugging.
>>>>>>         Monitoring and stats: In the last couple of years many web
>>>>>>             sites have added monitoring and statistics gathering
>>>>>>             capabilities (e.g., who clicks what, where, how long, on
>>>>>>             what page does the visitor exit the web site, etc.) in
>>>>>>             order to know how the web site is being used and then
>>>>>>             improve the web site.
>>>>>>         Significant Memory Usage Reduction: I've an idea that would
>>>>>>             significantly decrease the memory usage of Scala-Wicket and
>>>>>>             I plan to do a test implementation.
>>>>>>         Replace Java features: There are still some Java-isms that can
>>>>>>             be replaced with Scala equivalents.
>>>>>>         Port additional Java Wicket libraries to Scala.
>>>>>>         Enable multiple instances of a unit tests to be run at once.
>>>>>>         More: ????????????
>>>>>>
>>>>>>     I want to avoid using some of the WTF features of Scala (when a
>>>>>>         Java programmer looks at the code and says "WTF") in order to
>>>>>>         ease and accelerate acceptance by Java programmers; as
>>>>>>         examples, implicits can make code hard to understand and
>>>>>>         advanced Scala type usages, as James Gosling said, "makes one's
>>>>>>         head spin".
>>>>>>
>>>>>>
>>>>>> Help and Advice: How should Scala-Wicket be extended and released
>>>>>>
>>>>>>     Scala-Wicket is a port and evolution of Wicket, not a ground-up
>>>>>>         re-write. Given that, what would you do differently in Wicket
>>>>>>         now that there are years of experience using it?
>>>>>>
>>>>>>     How best to get a hosting site, release the code and build a
>>>>>>         community?
>>>>>>
>>>>>>
>>>>> If you're looking for a place to host it, I'd recommend starting with
>>>>> Github.  Git is where the crowd is headed, and Github is the easiest
>>>>> place
>>>>> to get up and running with it these days.
>>>>>
>>>>> You mentioned earlier the idea of it being an Apache project.  If you
>>>>> wanted
>>>>> it to be an Apache project, you would start at the Incubator (
>>>>> http://incubator.apache.org/).  The one barrier you'll have initially
>> is
>>>>> that Apache favors "community over code"... so it's not a great place
>> to
>>>>> start a one-man project.  Since this is a port of an existing Apache
>>>>> project, you might have more leniency, but you'd have to build a
>>>>> community
>>>>> around the project before you could ever "graduate" from the incubator.
>>>>>
>>>>> Probably Github is your best bet for now.  Build a community.  Then, if
>>>>> your
>>>>> community is in favor, move to Apache.  By that time, ASF might have
>> full
>>>>> git support.
>>>>>
>>>>>
>>>>>      Are there any mechanism to help fund such an open-source project?
>>>>>>
>>>>>>
>>>>> Best bet is to build a community.  Of course, if you can find some
>>>>> company
>>>>> that wants such a project, you can get monetary support to develop /
>>>>> maintain.  But that seems unlikely in this case with the limited number
>>>>> of
>>>>> companies looking for Scala out there, and especially since this is an
>>>>> unproven port of a large Java project.  So, start by getting folks like
>>>>> jWeekend involved - great coders who are already salivating for Scala.
>>>>>   Find
>>>>> other individuals such as yourself who are interested, and build a
>> group
>>>>> of
>>>>> core committers.
>>>>>
>>>>>
>>>>>   This is not meant to be a general announcement but rather a means
>>>>>> for me to get some initial advice as to how to proceed.
>>>>>>
>>>>>> Any help is appreciated.
>>>>>>
>>>>>> Richard Emberson
>>>>>>
>>>>>
>>>>>
>>>>> I'm impressed.  Quite an undertaking.
>>>>>
>>>>> --
>>>>> Jeremy Thomerson
>>>>> http://wickettraining.com
>>>>> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
>>>>>
>>>>>
>>>>
>>> --
>>> Quis custodiet ipsos custodes
>>>
>>
>

--
Quis custodiet ipsos custodes
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

James Carman
In reply to this post by Gerolf Seitz
I've got to try it!
On Jan 5, 2011 6:10 PM, "Gerolf Seitz" <[hidden email]> wrote:

>>
>> Is this in IntelliJ IDEA?
>>
>>
> yes
>
>
>> On Wed, Jan 5, 2011 at 6:04 PM, Gerolf Seitz <[hidden email]>
>> wrote:
>> > It's cmd+shift+G (OSX) and it works quite well ;)
>> >
>> > On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee <[hidden email]>
>> wrote:
>> >
>> >> You can paste a java class into a .scala file and it'll autoconvert.
>> >> there's a shortcut keystroke, too, but i don't remember what it is.
>> >>
>> >> On Wed, Jan 5, 2011 at 10:40 AM, richard emberson <
>> >> [hidden email]> wrote:
>> >>
>> >> > No IDE, I use Vim. Also, my build environment is Ant-based
>> >> > using scalac and javac.
>> >> >
>> >> > Of course, what I was doing was porting from Java to Scala.
>> >> > To that end I've got some 400 Vim scripts that aid in the
>> >> > port. For instance,
>> >> >
>> >> > :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1]
>> =/g
>> >> >
>> >> > converts
>> >> > final B a[] =
>> >> > to
>> >> > val a: Array[B] =
>> >> >
>> >> > I don't know if IDEs provide such scripting with regex support.
>> >> > Also, with a simple Vim script and key combination, I can be
>> >> > viewing a ported Scala file and jump to its corresponding source
>> >> > Java Wicket file - very useful when porting or debugging.
>> >> > Yea, IDEs can do stuff me and my Vim scripts can not do, but my
>> >> > fingers know Vim.
>> >> >
>> >> > I also built a JUnit driver class in Scala (and Java) that allowed
>> >> > me to execute a single test method in a given test class by setting
>> >> > two properties in a file that my Ant script reads. This was vital
>> >> > for hunting down bugs.
>> >> >
>> >> > I looked into the tool that allowed Vim to be the front-end and
>> >> > Eclipse to run in server mode which allows a Vim user to access
>> >> > many of the extra features the IDE offers, but, as of a couple of
>> >> > months ago, there was no Scala support in the tool.
>> >> >
>> >> > The father of Scala, Martin Odersky uses Emacs.
>> >> >
>> >> > Richard
>> >> >
>> >> >
>> >> >
>> >> > On 01/05/2011 12:38 AM, Juergen Donnerstag wrote:
>> >> >
>> >> >> Cool. May I ask which tools (IDE) you've been using and what your
>> >> >> experience with these tools has been.
>> >> >>
>> >> >> -Juergen
>> >> >>
>> >> >> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
>> >> >> <[hidden email]> wrote:
>> >> >>
>> >> >>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<
>> >> >>> [hidden email]
>> >> >>>
>> >> >>>> wrote:
>> >> >>>>
>> >> >>>
>> >> >>> Dev Wicketers,
>> >> >>>>
>> >> >>>> What: I have ported Wicket to Scala
>> >> >>>> A couple of months ago I took a 1.5 snapshot and ported to
>> Scala.
>> >> >>>> This encompasses all of the source and test code. As successive
>> 1.5
>> >> >>>> snapshots were released, I ported those differences to my Scala
>> >> >>>> version. I am current with 1.5 M3.
>> >> >>>>
>> >> >>>> The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>> >> >>>> counting all the println statements I put into the Scala code
>> >> >>>> for debugging). I used cloc (http://cloc.sourceforge.net/) to
>> >> >>>> count lines of code.
>> >> >>>>
>> >> >>>>
>> >> >>> I haven't used CLOC before. I've used Ohcount (
>> >> >>> http://www.ohloh.net/p/ohcount) and like it. I'll have to give
>> this a
>> >> >>> try.
>> >> >>>
>> >> >>>
>> >> >>> I have also replaced all of the Java collection classes with
>> >> >>>
>> >> >>>> Scala collection classes (though a small number of Java
>> collection
>> >> >>>> classes remain that did not have comparable Scala
>> implementations).
>> >> >>>>
>> >> >>>> I have changed many method return types from the Java returning
>> >> >>>> some "object" or "null" to Scala returning "Some(object)" or
>> "None"
>> >> >>>> (using the Scala Option[return-type] construct) - trying to
>> >> >>>> eliminate nulls.
>> >> >>>>
>> >> >>>> Lastly, I pushed the IModel[T] typing down to the Component
>> class
>> >> >>>> making get/set DefaultModel and get/set DefaultModelObject
>> strong
>> >> >>>> typed. This included using Scala companion object apply methods
>> >> >>>> which eliminated having to explicitly declare type parameters in
>> >> >>>> most end-user code (I had read that one of the objections to
>> >> >>>> pushing strong typing down to the Component class in Wicket was
>> >> >>>> that there were "too many notes", end-user code was too
>> verbose).
>> >> >>>>
>> >> >>>> It can not interoperate with Java Wicket because Scala compiles
>> to
>> >> >>>> JVM class files and so all of the classes in Java Wicket also
>> >> >>>> appear in Scala-Wicket.
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>> I have an "internal" name for my Scala port of Wicket which
>> >> >>>> acknowledges its Wicket heritage as well as advertises its
>> >> >>>> enterprise level capabilities. For external communications,
>> >> >>>> I am currently simply call it Scala-Wicket.
>> >> >>>>
>> >> >>>> Why: Scala is a better Java
>> >> >>>> I was introduced to Scala 9 months ago and quickly determined
>> that
>> >> >>>> it was a better Java (at least IMO). For Scala to succeed it
>> >> >>>> requires more programmers to use it. Many on the Scala mailing
>> >> >>>> lists were from a functional background and seemed not to
>> recognize
>> >> >>>> that Haskell and Lisp are not blindingly successful but, rather,
>> >> >>>> niche languages and that the heavy selling of Scala's function
>> and
>> >> >>>> typing capabilities might turn off Java programmers.
>> >> >>>>
>> >> >>>> Scala struck me in many ways as a strong-typed JavaScript, at
>> >> >>>> least, much of the code did not have to have type declarations
>> >> >>>> because the compiler could infer types in many cases. In
>> addition,
>> >> >>>> a whole lot of the Java boil-plate code was not needed. As such,
>> >> >>>> it could be sold as simply a better Java; a more-to-the-point
>> >> >>>> object oriented language with functional programming
>> in-the-small.
>> >> >>>>
>> >> >>>> To get more Java programmers to try Scala I looked for a
>> >> >>>> significant Java application with a strong support and user
>> >> >>>> community that I could port to Scala. I ended up with Wicket.
>> >> >>>> Wicket is an enterprise level web framework (unlike existing
>> >> >>>> Scale web frameworks which place restrictions on enterprise IT
>> >> >>>> organizations, e.g., by requiring sticky sessions). It is well
>> >> >>>> documented. And, as it turned out, very, very importantly it had
>> >> >>>> a large number of unit tests (the unit tests saved my butt,
>> >> >>>> without them I would never had succeeded in getting a port that
>> >> >>>> worked).
>> >> >>>>
>> >> >>>> No, Really, Why:
>> >> >>>> I like Scala and I took the time to learn it. Right now
>> about
>> >> >>>> 20% of programmers use Java while only some 0.4% use Scala.
>> >> >>>> I did not want my effort of learning Scala to be wasted so
>> my
>> >> >>>> solution is to increase the number of Scala programmers.
>> Where
>> >> >>>> to get them? Again, my solution is from the existing horde
>> of
>> >> >>>> Java programmers.
>> >> >>>>
>> >> >>>> Plans: Release, Evolve and Proselytize
>> >> >>>> I would like to release Scala-Wicket.
>> >> >>>> I do not know if Apache hosts anything other than Java code.
>> >> >>>> Growing a community is important.
>> >> >>>>
>> >> >>>> Still Todo:
>> >> >>>> Comments: All of the existing class and inline comments are
>> >> >>>> still Java related. This would have to be a long,
>> on-going
>> >> >>>> task to edit the comments so they reflect the code's
>> >> >>>> Scala usage.
>> >> >>>> Package path: The code still uses the "org.apache.wicket"
>> >> >>>> package path and this must be changed - unless this
>> became
>> >> >>>> an Apache project.
>> >> >>>> Author: I have quite literally looked at and touched every
>> line
>> >> >>>> of code but I have not yet felt comfortable with adding
>> >> >>>> myself as an author since, well, many changes were
>> >> >>>> syntactic and not semantic.
>> >> >>>> Refactor with Traits: Currently the port uses Scala traits
>> like
>> >> >>>> Java interfaces but it should be possible to factor the
>> >> >>>> common code out into the traits. This would result in
>> many
>> >> >>>> of the interfaces, the "I" files, such as IModel.scala,
>> >> >>>> going away.
>> >> >>>> Some general refactoring:
>> >> >>>> As an example, consider factoring out the IModel[T] from
>> >> >>>> Component. Half the time a user wants a Component with
>> >> >>>> no model, so, if there was a HasModel trait:
>> >> >>>> class Model[T](var value: T) {
>> >> >>>> def getObject: T = value
>> >> >>>> def setObject(value: T): Unit = this.value =
>> value
>> >> >>>> }
>> >> >>>> trait HasModel[T] {
>> >> >>>> var model: Model[T]
>> >> >>>> def getDefaultModel: IModel[T] = model
>> >> >>>> def setDefaultModel(model: IModel[T]): this.type =
>> {
>> >> >>>> ....
>> >> >>>> this
>> >> >>>> }
>> >> >>>> def getDefaultModelObject: Option[T] = {
>> >> >>>> ....
>> >> >>>> }
>> >> >>>> def setDefaultModelObject(obj: T): this.type = {
>> >> >>>> ....
>> >> >>>> this
>> >> >>>> }
>> >> >>>> }
>> >> >>>> The Component hierarchy would have no model support.
>> >> >>>> The user could add model support when needed:
>> >> >>>> val form = new Form("hi")
>> >> >>>> with HasModel[Int] { var model = new Model(42) }
>> >> >>>> Just an Idea.
>> >> >>>> STM: There are a number of Scala STM projects and I do not
>> know
>> >> >>>> if it is useful to add STM capabilities to Scala-Wicket.
>> >> >>>> RBAC: I've written a Scala implementation of the NIST RBAC
>> >> >>>> recommended standard and might consider adding it.
>> >> >>>> Logging: Adding a Scala-based logging framework to aid user
>> >> >>>> debugging.
>> >> >>>> Monitoring and stats: In the last couple of years many web
>> >> >>>> sites have added monitoring and statistics gathering
>> >> >>>> capabilities (e.g., who clicks what, where, how long, on
>> >> >>>> what page does the visitor exit the web site, etc.) in
>> >> >>>> order to know how the web site is being used and then
>> >> >>>> improve the web site.
>> >> >>>> Significant Memory Usage Reduction: I've an idea that would
>> >> >>>> significantly decrease the memory usage of Scala-Wicket
>> and
>> >> >>>> I plan to do a test implementation.
>> >> >>>> Replace Java features: There are still some Java-isms that
>> can
>> >> >>>> be replaced with Scala equivalents.
>> >> >>>> Port additional Java Wicket libraries to Scala.
>> >> >>>> Enable multiple instances of a unit tests to be run at once.
>> >> >>>> More: ????????????
>> >> >>>>
>> >> >>>> I want to avoid using some of the WTF features of Scala (when a
>> >> >>>> Java programmer looks at the code and says "WTF") in order
>> to
>> >> >>>> ease and accelerate acceptance by Java programmers; as
>> >> >>>> examples, implicits can make code hard to understand and
>> >> >>>> advanced Scala type usages, as James Gosling said, "makes
>> one's
>> >> >>>> head spin".
>> >> >>>>
>> >> >>>>
>> >> >>>> Help and Advice: How should Scala-Wicket be extended and released
>> >> >>>>
>> >> >>>> Scala-Wicket is a port and evolution of Wicket, not a ground-up
>> >> >>>> re-write. Given that, what would you do differently in
>> Wicket
>> >> >>>> now that there are years of experience using it?
>> >> >>>>
>> >> >>>> How best to get a hosting site, release the code and build a
>> >> >>>> community?
>> >> >>>>
>> >> >>>>
>> >> >>> If you're looking for a place to host it, I'd recommend starting
>> with
>> >> >>> Github. Git is where the crowd is headed, and Github is the
easiest

>> >> >>> place
>> >> >>> to get up and running with it these days.
>> >> >>>
>> >> >>> You mentioned earlier the idea of it being an Apache project. If
>> you
>> >> >>> wanted
>> >> >>> it to be an Apache project, you would start at the Incubator (
>> >> >>> http://incubator.apache.org/). The one barrier you'll have
>> initially
>> >> is
>> >> >>> that Apache favors "community over code"... so it's not a great
>> place
>> >> to
>> >> >>> start a one-man project. Since this is a port of an existing
Apache
>> >> >>> project, you might have more leniency, but you'd have to build a
>> >> >>> community
>> >> >>> around the project before you could ever "graduate" from the
>> incubator.
>> >> >>>
>> >> >>> Probably Github is your best bet for now. Build a community. Then,
>> if
>> >> >>> your
>> >> >>> community is in favor, move to Apache. By that time, ASF might
have

>> >> full
>> >> >>> git support.
>> >> >>>
>> >> >>>
>> >> >>> Are there any mechanism to help fund such an open-source
>> project?
>> >> >>>>
>> >> >>>>
>> >> >>> Best bet is to build a community. Of course, if you can find some
>> >> >>> company
>> >> >>> that wants such a project, you can get monetary support to develop
/
>> >> >>> maintain. But that seems unlikely in this case with the limited
>> number
>> >> >>> of
>> >> >>> companies looking for Scala out there, and especially since this
is

>> an
>> >> >>> unproven port of a large Java project. So, start by getting folks
>> like
>> >> >>> jWeekend involved - great coders who are already salivating for
>> Scala.
>> >> >>> Find
>> >> >>> other individuals such as yourself who are interested, and build a
>> >> group
>> >> >>> of
>> >> >>> core committers.
>> >> >>>
>> >> >>>
>> >> >>> This is not meant to be a general announcement but rather a means
>> >> >>>> for me to get some initial advice as to how to proceed.
>> >> >>>>
>> >> >>>> Any help is appreciated.
>> >> >>>>
>> >> >>>> Richard Emberson
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>> I'm impressed. Quite an undertaking.
>> >> >>>
>> >> >>> --
>> >> >>> Jeremy Thomerson
>> >> >>> http://wickettraining.com
>> >> >>> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>> >> >>>
>> >> >>>
>> >> >>
>> >> > --
>> >> > Quis custodiet ipsos custodes
>> >> >
>> >>
>> >
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Cemal Bayramoglu
In reply to this post by richard emberson
Richard,

This would effectively result in Java code translated directly to
Scala, pretty naively.
From what you describe, you have already manually done much better than that.

As you have already hinted at in your previous posts, one  of the key
points of this would be to take advantage of the fantastic features
(OO & functional) of Scala, rather than effectively implementing Java
idioms in Scala.

Regards - Cemal
jWeekend
Training, Consulting, Development
http://jWeekend.com






On 5 January 2011 23:23, richard emberson <[hidden email]> wrote:

> So there is an IDE that you can point at a directory tree and
> tell it to convert all of the Java files to Scala files.
> Does it do a 100% conversion, 90%, 50% or 10% (on average)?
> Do you have a link to a page documenting this feature?
>
> Thanks
> Richard
>
> On 01/05/2011 03:04 PM, Gerolf Seitz wrote:
>>
>> It's cmd+shift+G (OSX) and it works quite well ;)
>>
>> On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee<[hidden email]>  wrote:
>>
>>> You can paste a java class into a .scala file and it'll autoconvert.
>>>  there's a shortcut keystroke, too, but i don't remember what it is.
>>>
>>> On Wed, Jan 5, 2011 at 10:40 AM, richard emberson<
>>> [hidden email]>  wrote:
>>>
>>>> No IDE, I use Vim. Also, my build environment is Ant-based
>>>> using scalac and javac.
>>>>
>>>> Of course, what I was doing was porting from Java to Scala.
>>>> To that end I've got some 400 Vim scripts that aid in the
>>>> port. For instance,
>>>>
>>>> :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g
>>>>
>>>> converts
>>>>    final B a[] =
>>>> to
>>>>    val a: Array[B] =
>>>>
>>>> I don't know if IDEs provide such scripting with regex support.
>>>> Also, with a simple Vim script and key combination, I can be
>>>> viewing a ported Scala file and jump to its corresponding source
>>>> Java Wicket file - very useful when porting or debugging.
>>>> Yea, IDEs can do stuff me and my Vim scripts can not do, but my
>>>> fingers know Vim.
>>>>
>>>> I also built a JUnit driver class in Scala (and Java) that allowed
>>>> me to execute a single test method in a given test class by setting
>>>> two properties in a file that my Ant script reads. This was vital
>>>> for hunting down bugs.
>>>>
>>>> I looked into the tool that allowed Vim to be the front-end and
>>>> Eclipse to run in server mode which allows a Vim user to access
>>>> many of the extra features the IDE offers, but, as of a couple of
>>>> months ago, there was no Scala support in the tool.
>>>>
>>>> The father of Scala, Martin Odersky uses Emacs.
>>>>
>>>> Richard
>>>>
>>>>
>>>>
>>>> On 01/05/2011 12:38 AM, Juergen Donnerstag wrote:
>>>>
>>>>> Cool. May I ask which tools (IDE) you've been using and what your
>>>>> experience with these tools has been.
>>>>>
>>>>> -Juergen
>>>>>
>>>>> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson
>>>>> <[hidden email]>   wrote:
>>>>>
>>>>>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<
>>>>>> [hidden email]
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>>  Dev Wicketers,
>>>>>>>
>>>>>>> What: I have ported Wicket to Scala
>>>>>>>    A couple of months ago I took a 1.5 snapshot and ported to Scala.
>>>>>>>    This encompasses all of the source and test code. As successive
>>>>>>> 1.5
>>>>>>>    snapshots were released, I ported those differences to my Scala
>>>>>>>    version. I am current with 1.5 M3.
>>>>>>>
>>>>>>>    The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not
>>>>>>>    counting all the println statements I put into the Scala code
>>>>>>>    for debugging). I used cloc (http://cloc.sourceforge.net/) to
>>>>>>>    count lines of code.
>>>>>>>
>>>>>>>
>>>>>> I haven't used CLOC before.  I've used Ohcount (
>>>>>> http://www.ohloh.net/p/ohcount) and like it.  I'll have to give this a
>>>>>> try.
>>>>>>
>>>>>>
>>>>>>   I have also replaced all of the Java collection classes with
>>>>>>
>>>>>>>    Scala collection classes (though a small number of Java collection
>>>>>>>    classes remain that did not have comparable Scala
>>>>>>> implementations).
>>>>>>>
>>>>>>>    I have changed many method return types from the Java returning
>>>>>>>    some "object" or "null" to Scala returning "Some(object)" or
>>>>>>> "None"
>>>>>>>    (using the Scala Option[return-type] construct) - trying to
>>>>>>>    eliminate nulls.
>>>>>>>
>>>>>>>    Lastly, I pushed the IModel[T] typing down to the Component class
>>>>>>>    making get/set DefaultModel and get/set DefaultModelObject strong
>>>>>>>    typed.  This included using Scala companion object apply methods
>>>>>>>    which eliminated having to explicitly declare type parameters in
>>>>>>>    most end-user code (I had read that one of the objections to
>>>>>>>    pushing strong typing down to the Component class in Wicket was
>>>>>>>    that there were "too many notes", end-user code was too verbose).
>>>>>>>
>>>>>>>    It can not interoperate with Java Wicket because Scala compiles to
>>>>>>>    JVM class files and so all of the classes in Java Wicket also
>>>>>>>    appear in Scala-Wicket.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>     I have an "internal" name for my Scala port of Wicket which
>>>>>>>
>>>>>>>    acknowledges its Wicket heritage as well as advertises its
>>>>>>>    enterprise level capabilities. For external communications,
>>>>>>>    I am currently simply call it Scala-Wicket.
>>>>>>>
>>>>>>> Why: Scala is a better Java
>>>>>>>    I was introduced to Scala 9 months ago and quickly determined that
>>>>>>>    it was a better Java (at least IMO). For Scala to succeed it
>>>>>>>    requires more programmers to use it. Many on the Scala mailing
>>>>>>>    lists were from a functional background and seemed not to
>>>>>>> recognize
>>>>>>>    that Haskell and Lisp are not blindingly successful but, rather,
>>>>>>>    niche languages and that the heavy selling of Scala's function and
>>>>>>>    typing capabilities might turn off Java programmers.
>>>>>>>
>>>>>>>    Scala struck me in many ways as a strong-typed JavaScript, at
>>>>>>>    least, much of the code did not have to have type declarations
>>>>>>>    because the compiler could infer types in many cases. In addition,
>>>>>>>    a whole lot of the Java boil-plate code was not needed. As such,
>>>>>>>    it could be sold as simply a better Java; a more-to-the-point
>>>>>>>    object oriented language with functional programming in-the-small.
>>>>>>>
>>>>>>>    To get more Java programmers to try Scala I looked for a
>>>>>>>    significant Java application with a strong support and user
>>>>>>>    community that I could port to Scala. I ended up with Wicket.
>>>>>>>    Wicket is an enterprise level web framework (unlike existing
>>>>>>>    Scale web frameworks which place restrictions on enterprise IT
>>>>>>>    organizations, e.g., by requiring sticky sessions).  It is well
>>>>>>>    documented. And, as it turned out, very, very importantly it had
>>>>>>>    a large number of unit tests (the unit tests saved my butt,
>>>>>>>    without them I would never had succeeded in getting a port that
>>>>>>>    worked).
>>>>>>>
>>>>>>>    No, Really, Why:
>>>>>>>        I like Scala and I took the time to learn it. Right now about
>>>>>>>        20% of programmers use Java while only some 0.4% use Scala.
>>>>>>>        I did not want my effort of learning Scala to be wasted so my
>>>>>>>        solution is to increase the number of Scala programmers. Where
>>>>>>>        to get them? Again, my solution is from the existing horde of
>>>>>>>        Java programmers.
>>>>>>>
>>>>>>> Plans: Release, Evolve and Proselytize
>>>>>>>    I would like to release Scala-Wicket.
>>>>>>>    I do not know if Apache hosts anything other than Java code.
>>>>>>>    Growing a community is important.
>>>>>>>
>>>>>>>    Still Todo:
>>>>>>>        Comments: All of the existing class and inline comments are
>>>>>>>            still Java related.  This would have to be a long,
>>>>>>> on-going
>>>>>>>            task to edit the comments so they reflect the code's
>>>>>>>            Scala usage.
>>>>>>>        Package path: The code still uses the "org.apache.wicket"
>>>>>>>            package path and this must be changed - unless this became
>>>>>>>            an Apache project.
>>>>>>>        Author: I have quite literally looked at and touched every
>>>>>>> line
>>>>>>>            of code but I have not yet felt comfortable with adding
>>>>>>>            myself as an author since, well, many changes were
>>>>>>>            syntactic and not semantic.
>>>>>>>        Refactor with Traits: Currently the port uses Scala traits
>>>>>>> like
>>>>>>>            Java interfaces but it should be possible to factor the
>>>>>>>            common code out into the traits. This would result in many
>>>>>>>            of the interfaces, the "I" files, such as IModel.scala,
>>>>>>>            going away.
>>>>>>>        Some general refactoring:
>>>>>>>            As an example, consider factoring out the IModel[T] from
>>>>>>>            Component. Half the time a user wants a Component with
>>>>>>>            no model, so, if there was a HasModel trait:
>>>>>>>                class Model[T](var value: T) {
>>>>>>>                    def getObject: T = value
>>>>>>>                    def setObject(value: T): Unit = this.value = value
>>>>>>>                }
>>>>>>>                trait HasModel[T] {
>>>>>>>                  var model: Model[T]
>>>>>>>                  def getDefaultModel: IModel[T] = model
>>>>>>>                  def setDefaultModel(model: IModel[T]): this.type = {
>>>>>>>                    ....
>>>>>>>                    this
>>>>>>>                  }
>>>>>>>                  def getDefaultModelObject: Option[T] = {
>>>>>>>                    ....
>>>>>>>                  }
>>>>>>>                  def setDefaultModelObject(obj: T): this.type = {
>>>>>>>                    ....
>>>>>>>                    this
>>>>>>>                  }
>>>>>>>                }
>>>>>>>            The Component hierarchy would have no model support.
>>>>>>>            The user could add model support when needed:
>>>>>>>                val form = new Form("hi")
>>>>>>>                  with HasModel[Int] { var model = new Model(42) }
>>>>>>>            Just an Idea.
>>>>>>>        STM: There are a number of Scala STM projects and I do not
>>>>>>> know
>>>>>>>            if it is useful to add STM capabilities to Scala-Wicket.
>>>>>>>        RBAC: I've written a Scala implementation of the NIST RBAC
>>>>>>>            recommended standard and might consider adding it.
>>>>>>>        Logging: Adding a Scala-based logging framework to aid user
>>>>>>>            debugging.
>>>>>>>        Monitoring and stats: In the last couple of years many web
>>>>>>>            sites have added monitoring and statistics gathering
>>>>>>>            capabilities (e.g., who clicks what, where, how long, on
>>>>>>>            what page does the visitor exit the web site, etc.) in
>>>>>>>            order to know how the web site is being used and then
>>>>>>>            improve the web site.
>>>>>>>        Significant Memory Usage Reduction: I've an idea that would
>>>>>>>            significantly decrease the memory usage of Scala-Wicket
>>>>>>> and
>>>>>>>            I plan to do a test implementation.
>>>>>>>        Replace Java features: There are still some Java-isms that can
>>>>>>>            be replaced with Scala equivalents.
>>>>>>>        Port additional Java Wicket libraries to Scala.
>>>>>>>        Enable multiple instances of a unit tests to be run at once.
>>>>>>>        More: ????????????
>>>>>>>
>>>>>>>    I want to avoid using some of the WTF features of Scala (when a
>>>>>>>        Java programmer looks at the code and says "WTF") in order to
>>>>>>>        ease and accelerate acceptance by Java programmers; as
>>>>>>>        examples, implicits can make code hard to understand and
>>>>>>>        advanced Scala type usages, as James Gosling said, "makes
>>>>>>> one's
>>>>>>>        head spin".
>>>>>>>
>>>>>>>
>>>>>>> Help and Advice: How should Scala-Wicket be extended and released
>>>>>>>
>>>>>>>    Scala-Wicket is a port and evolution of Wicket, not a ground-up
>>>>>>>        re-write. Given that, what would you do differently in Wicket
>>>>>>>        now that there are years of experience using it?
>>>>>>>
>>>>>>>    How best to get a hosting site, release the code and build a
>>>>>>>        community?
>>>>>>>
>>>>>>>
>>>>>> If you're looking for a place to host it, I'd recommend starting with
>>>>>> Github.  Git is where the crowd is headed, and Github is the easiest
>>>>>> place
>>>>>> to get up and running with it these days.
>>>>>>
>>>>>> You mentioned earlier the idea of it being an Apache project.  If you
>>>>>> wanted
>>>>>> it to be an Apache project, you would start at the Incubator (
>>>>>> http://incubator.apache.org/).  The one barrier you'll have initially
>>>
>>> is
>>>>>>
>>>>>> that Apache favors "community over code"... so it's not a great place
>>>
>>> to
>>>>>>
>>>>>> start a one-man project.  Since this is a port of an existing Apache
>>>>>> project, you might have more leniency, but you'd have to build a
>>>>>> community
>>>>>> around the project before you could ever "graduate" from the
>>>>>> incubator.
>>>>>>
>>>>>> Probably Github is your best bet for now.  Build a community.  Then,
>>>>>> if
>>>>>> your
>>>>>> community is in favor, move to Apache.  By that time, ASF might have
>>>
>>> full
>>>>>>
>>>>>> git support.
>>>>>>
>>>>>>
>>>>>>     Are there any mechanism to help fund such an open-source project?
>>>>>>>
>>>>>>>
>>>>>> Best bet is to build a community.  Of course, if you can find some
>>>>>> company
>>>>>> that wants such a project, you can get monetary support to develop /
>>>>>> maintain.  But that seems unlikely in this case with the limited
>>>>>> number
>>>>>> of
>>>>>> companies looking for Scala out there, and especially since this is an
>>>>>> unproven port of a large Java project.  So, start by getting folks
>>>>>> like
>>>>>> jWeekend involved - great coders who are already salivating for Scala.
>>>>>>  Find
>>>>>> other individuals such as yourself who are interested, and build a
>>>
>>> group
>>>>>>
>>>>>> of
>>>>>> core committers.
>>>>>>
>>>>>>
>>>>>>  This is not meant to be a general announcement but rather a means
>>>>>>>
>>>>>>> for me to get some initial advice as to how to proceed.
>>>>>>>
>>>>>>> Any help is appreciated.
>>>>>>>
>>>>>>> Richard Emberson
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm impressed.  Quite an undertaking.
>>>>>>
>>>>>> --
>>>>>> Jeremy Thomerson
>>>>>> http://wickettraining.com
>>>>>> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Quis custodiet ipsos custodes
>>>>
>>>
>>
>
> --
> Quis custodiet ipsos custodes
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Jonathan Locke
In reply to this post by richard emberson
Not so sure that doing a simple fork of Wicket into Scala is such a great idea. And at the end of the day you probably couldn't call it Wicket without Apache permission, which seems unlikely. But creating a Wicket-inspired framework in Scala sounds like a good idea to me. Have you taken a look at David Pollak's Lift project?

Regarding Scala, I think it's a good sign that people are interested in advancing the state of the art. And I think Martin and company have found some of the problems that need solving and to their great credit done something about them, even if only 0.4% of programmers are using Scala so far. Unfortunately, I don't think a large or powerful or killer set of features is what makes or breaks a language in terms of widespread adoption. And I *especially* don't think that economy of expression makes a language "better", particularly where large teams are concerned. Clarity, precision and simplicity are far more important than brevity and power.

Jon

"Less is more."
http://www.amazon.com/Coding-Software-Design-Process-ebook/dp/B0042X99SA/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

ghexsel
  I'll have to say I looked at Lift, and although it was greatly improved
since 1.0, it doesn't have the awesome separation of concerns that wicket
does.  Even in the tutorial, the markup and the templates leak into each
other.  Wicket's greatest asset was always IMO the fact that the HTML itself
can be almost unmodified between designer and programmer (of course, usually
it pays to create components).

  I've made a couple of toy projects in Scala/Wicket, and the biggest pain
was to get the collections and generics right.  I don't much like the
implicit conversions (anywhere, even boxing and unboxing end up doing weird
stuff once in a while), so I always ended up having to do it by hand.  It
made life easier to keep using the Scala collections, and just convert it to
Java collections in the Wicket Models, but once in a while it still messed
me up...

  I would love to see a wicket api that used the Scala collections and made
models use SModels or something like that.


PS.: that's my opinion as a lurker... not a Wicket dev



On Thu, Jan 6, 2011 at 12:19 PM, Jonathan Locke <[hidden email]>wrote:

>
> Not so sure that doing a simple fork of Wicket into Scala is such a great
> idea. And at the end of the day you probably couldn't call it Wicket
> without
> Apache permission, which seems unlikely. But creating a Wicket-inspired
> framework in Scala sounds like a good idea to me. Have you taken a look at
> David Pollak's Lift project?
>
> Regarding Scala, I think it's a good sign that people are interested in
> advancing the state of the art. And I think Martin and company have found
> some of the problems that need solving and to their great credit done
> something about them, even if only 0.4% of programmers are using Scala so
> far. Unfortunately, I don't think a large or powerful or killer set of
> features is what makes or breaks a language in terms of widespread
> adoption.
> And I *especially* don't think that economy of expression makes a language
> "better", particularly where large teams are concerned. Clarity, precision
> and simplicity are far more important than brevity and power.
>
> Jon
>
> "Less is more."
> http://www.amazon.com/Coding-Software-Design-Process-ebook/dp/B0042X99SA/
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3178126.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

richard emberson
A sympathetic voice on the Wicket mailing list, greetings.
I don't know if you have followed it all but I have ported
Wicket to Scala, replaced the Java collections with Scala
collections, pushed the IModel[T] strong typing down to the
Component object and have plans for more changes. But,
I wanted to get some advice and help. With regards to Scala,
where should the Scala-Wicket be heading?
I also believe that emphasising the non-object oriented features
of Scala will make it harder to attract Java programmers.
So, I want to use Scala's functional, advanced type classes,
implicits, and other such features very carefully if at all.

One idea that I've thought about was to factor out IModel from
Component:
     Half the time a user wants a Component with
     no model, so, if there was a HasModel trait:
         class Model[T](var value: T) {
             def getObject: T = value
             def setObject(value: T): Unit = this.value = value
         }
         trait HasModel[T] {
           var model: Model[T]
           def getDefaultModel: IModel[T] = model
           def setDefaultModel(model: IModel[T]): this.type = {
             ....
             this
           }
           def getDefaultModelObject: Option[T] = {
             ....
           }
           def setDefaultModelObject(obj: T): this.type = {
             ....
             this
           }
         }
     The Component hierarchy would have no model support.
     The user could add model support when needed:
         val form = new Form("hi")
           with HasModel[Int] { var model = new Model(42) }
     Just an Idea.

Richard


On 01/06/2011 03:43 PM, Gustavo Hexsel wrote:

>    I'll have to say I looked at Lift, and although it was greatly improved
> since 1.0, it doesn't have the awesome separation of concerns that wicket
> does.  Even in the tutorial, the markup and the templates leak into each
> other.  Wicket's greatest asset was always IMO the fact that the HTML itself
> can be almost unmodified between designer and programmer (of course, usually
> it pays to create components).
>
>    I've made a couple of toy projects in Scala/Wicket, and the biggest pain
> was to get the collections and generics right.  I don't much like the
> implicit conversions (anywhere, even boxing and unboxing end up doing weird
> stuff once in a while), so I always ended up having to do it by hand.  It
> made life easier to keep using the Scala collections, and just convert it to
> Java collections in the Wicket Models, but once in a while it still messed
> me up...
>
>    I would love to see a wicket api that used the Scala collections and made
> models use SModels or something like that.
>
>
> PS.: that's my opinion as a lurker... not a Wicket dev
>
>
>
> On Thu, Jan 6, 2011 at 12:19 PM, Jonathan Locke<[hidden email]>wrote:
>
>>
>> Not so sure that doing a simple fork of Wicket into Scala is such a great
>> idea. And at the end of the day you probably couldn't call it Wicket
>> without
>> Apache permission, which seems unlikely. But creating a Wicket-inspired
>> framework in Scala sounds like a good idea to me. Have you taken a look at
>> David Pollak's Lift project?
>>
>> Regarding Scala, I think it's a good sign that people are interested in
>> advancing the state of the art. And I think Martin and company have found
>> some of the problems that need solving and to their great credit done
>> something about them, even if only 0.4% of programmers are using Scala so
>> far. Unfortunately, I don't think a large or powerful or killer set of
>> features is what makes or breaks a language in terms of widespread
>> adoption.
>> And I *especially* don't think that economy of expression makes a language
>> "better", particularly where large teams are concerned. Clarity, precision
>> and simplicity are far more important than brevity and power.
>>
>> Jon
>>
>> "Less is more."
>> http://www.amazon.com/Coding-Software-Design-Process-ebook/dp/B0042X99SA/
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3178126.html
>> Sent from the Forum for Wicket Core developers mailing list archive at
>> Nabble.com.
>>
>

--
Quis custodiet ipsos custodes
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

richard emberson
In reply to this post by Jonathan Locke

Everyone has opinions, myself included.

Curious the mention of Lift. It highlights Scala's
"functional goodies and type classes" which is certainly the
wrong approach - more in line with being less clear and less
simple.  It is actually recommended that a Ruby programmer
would have a easier time using it. Kind of like going from one
ghetto to another.

On the other hand, with appropriate coding guidelines, Scala
can be clearer, more precise and simpler while also being
briefer and more powerful than Java ... or should I say Java 7,
or, more to the point, Java 8. With the right approach, one can
migrate the large number of the Java programmers who are not
to old to move forward to a better language; the
politics of "The Structure of Scientific Revolutions" seem to
always come into play.

And, of course, with poor guidelines one can be involved with
a poor Java project, which is to say, guidelines can
make or break how a project does using most any language.

Some may disagree and are comfortable with Java, fine;
without such Java supporters the JVM will not move forward.


Richard

--
Quis custodiet ipsos custodes
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Jonathan Locke
Kuhn's "The Structure of Scientific Revolutions" has to do with people denying *the truth* when there are radical paradigm shifts in knowledge. I hardly think Scala qualifies for this analogy. Most of what Scala does has already been done in one form or another. What it represents is the application of long-existing knowledge from universities to *industrial* problems. As did Java.

I do not deny that Scala is better than Java in terms of its abstract approach to a variety of problems that Java doesn't and probably never will solve well (and these are problems that I am excited to see solved). What I am saying, however, is that your idea that it's going to get widespread adoption is very naive regarding the contexts where it would need to be applied. I think Scala is going to become difficult to follow in the absence of these magical coding guidelines (which are always bent or ignored) much more quickly than Java does, which means it is going to prove exceptionally hard to manage on a large team. Which is going to make it difficult for managers to chose Scala (they don't want to make their own job harder or riskier). They have to understand and be comfortable with all these deep and dangerous features and techniques. Which really means that they have to be fairly top-flight coders. I don't know about you, but relatively few of my bosses have been this intellectually adventurous or willing to take on risk (and for good reason: they are there (unfortunately perhaps) to produce business results, not technical excellence).

I think Scala's forte is going to be allowing very small teams where everyone understands all aspects of Scala fairly deeply (i.e., you'd better understand monads and Scala's type system fully because SOMEONE on your team will use a feature or technique if it exists!) to produce amazing results *very* quickly. That is something of a revolution in itself, but I think it will be a cottage industry relative to the size rest of the software industry. This is not necessarily a bad thing. If you want to work with smart people, Scala is going to be a pretty quick way of identifying smart people! I know this from experience: I can't even understand on several readings a lot of my friend Greg's posts about Scala and monads and mathematics. I would need to go back to graduate school in math and I'd probably need an IQ upgrade to boot.

I know this sounds awfully Dilbert (and maybe that's who I've become), but at a mid-sized or large company (which is where most people work), what you want in a language is something that protects you from your co-workers. In my experience, even the "advanced" features of C++ and Java have consistently been abused and even wrecked whole projects.

All this said, Scala is probably a god-send to small startups and university spin-offs. And I think it's an important stake in the ground because it references a future wider-scale industrial software revolution that eventually will occur when someone more practical sits down and figures out how to pack Scala's features (and some things it didn't address) into a language that's as easy to learn and read and work with as Java. My advice to you is this: don't get caught up in the politics of technology adoption. You will only find yourself frustrated and disappointed because at the end of the day, it's a business world not a technology world. Instead go find the cool kids and hack away in Scala on some crazy new startup that really will change the world. Odds are you'll beat the pants off your Java-based competitors on time-to-market. And if you're wondering why I don't do that, it's because of all this green paper stuff they keep throwing at me. Maybe I really have gotten old.

Jon

"Less is more."
http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala-Wicket Help and Advice

Martin Makundi
I would adopt scala immediately if it had all the IDE tools Java has
with equal reliability (amount of showstopper/awkward bugs).

So guess it's just a matter of time, if nobody comes up with something better.

Lots of people are taught into coding java (as if that helps ;), so
one day when people are taught scala or its successors, it might be
perceived more mainstreamn than now.

Anywayz.. in 50 yrs or so, computers will be doing the coding automatically ;))

**
Martin

2011/1/7 Jonathan Locke <[hidden email]>:

>
> Kuhn's "The Structure of Scientific Revolutions" has to do with people
> denying *the truth* when there are radical paradigm shifts in knowledge. I
> hardly think Scala qualifies for this analogy. Most of what Scala does has
> already been done in one form or another. What it represents is the
> application of long-existing knowledge from universities to *industrial*
> problems. As did Java.
>
> I do not deny that Scala is better than Java in terms of its abstract
> approach to a variety of problems that Java doesn't and probably never will
> solve well (and these are problems that I am excited to see solved). What I
> am saying, however, is that your idea that it's going to get widespread
> adoption is very naive regarding the contexts where it would need to be
> applied. I think Scala is going to become difficult to follow in the absence
> of these magical coding guidelines (which are always bent or ignored) much
> more quickly than Java does, which means it is going to prove exceptionally
> hard to manage on a large team. Which is going to make it difficult for
> managers to chose Scala (they don't want to make their own job harder or
> riskier). They have to understand and be comfortable with all these deep and
> dangerous features and techniques. Which really means that they have to be
> fairly top-flight coders. I don't know about you, but relatively few of my
> bosses have been this intellectually adventurous or willing to take on risk
> (and for good reason: they are there (unfortunately perhaps) to produce
> business results, not technical excellence).
>
> I think Scala's forte is going to be allowing very small teams where
> everyone understands all aspects of Scala fairly deeply (i.e., you'd better
> understand monads and Scala's type system fully because SOMEONE on your team
> will use a feature or technique if it exists!) to produce amazing results
> *very* quickly. That is something of a revolution in itself, but I think it
> will be a cottage industry relative to the size rest of the software
> industry. This is not necessarily a bad thing. If you want to work with
> smart people, Scala is going to be a pretty quick way of identifying smart
> people! I know this from experience: I can't even understand on several
> readings a lot of my friend Greg's posts about Scala and monads and
> mathematics. I would need to go back to graduate school in math and I'd
> probably need an IQ upgrade to boot.
>
> I know this sounds awfully Dilbert (and maybe that's who I've become), but
> at a mid-sized or large company (which is where most people work), what you
> want in a language is something that protects you from your co-workers. In
> my experience, even the "advanced" features of C++ and Java have
> consistently been abused and even wrecked whole projects.
>
> All this said, Scala is probably a god-send to small startups and university
> spin-offs. And I think it's an important stake in the ground because it
> references a future wider-scale industrial software revolution that
> eventually will occur when someone more practical sits down and figures out
> how to pack Scala's features (and some things it didn't address) into a
> language that's as easy to learn and read and work with as Java. My advice
> to you is this: don't get caught up in the politics of technology adoption.
> You will only find yourself frustrated and disappointed because at the end
> of the day, it's a business world not a technology world. Instead go find
> the cool kids and hack away in Scala on some crazy new startup that really
> will change the world. Odds are you'll beat the pants off your Java-based
> competitors on time-to-market. And if you're wondering why I don't do that,
> it's because of all this green paper stuff they keep throwing at me. Maybe I
> really have gotten old.
>
> Jon
>
> "Less is more."
> http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3181566.html
> Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
>
123
Loading...