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 > > >
