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 via email to