Is this in IntelliJ IDEA?

On Wed, Jan 5, 2011 at 6:04 PM, Gerolf Seitz <gerolf.se...@gmail.com> wrote:
> It's cmd+shift+G (OSX) and it works quite well ;)
>
> On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee <evancho...@gmail.com> 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 <
>> richard.ember...@gmail.com> 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
>> >> <jer...@wickettraining.com>  wrote:
>> >>
>> >>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson<
>> >>> richard.ember...@gmail.com
>> >>>
>> >>>> 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 via email to