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