There seems to be some similarities with gogo, namely: - invocation of arbitrary methods - higher order functions - aliasing classes
On a closer look however the approaches seem quite different, on one hand we have TSL and an extension mechanism based on commands, on the other hand we have scala which its capability to provide DSL which for the user may look very similar to commands. In gogo a new language (TSL) is provided and new functionality implemented (where the standard keeps the syntax simple for the benefit of both for implementors and users) , with scala the DSL hides the complexity of the full fledged functional and oo language to keep it simple for the user. Reto On Wed, Jul 7, 2010 at 6:48 PM, Richard S. Hall <he...@ungoverned.org>wrote: > On 7/7/10 12:19, Reto Bachmann-Gmuer wrote: > >> I think the console might provide benefits to different audiences at >> different levels of its development >> >> - In a first step the console will be an alternative to the normal >> scala >> console with the advantage that the classpath can be changed at >> runtime. >> With the current scala console it has to be restarted with the >> additional >> jars in the classpath, with osgi-scala one would simply have to enter >> "install<bundle-url>". At this stage doing OSGi management task is >> possible >> via a global BundleContext instance, but rather tedious as only little >> shortcuts (like the install command) are available >> - As a next step support for easily accessing arbitrary service >> instance >> is added, this allows to quickly test and use them with scala script >> code. >> For this the already mentioned Scala Modules might be a good >> foundation. >> - The scala DSL (domain specific language) shall be extended to provide >> the full set of OSGi-console commands. The commands shall work as >> expected >> by somebody who knows nothing about scala. However by actually being >> scala >> advanced operation like passing a filter-function to the ps/lb command >> is >> posible too. >> >> I hope this makes the vision a little clearer. >> > > It does. And certainly makes me think of Gogo. I don't know enough to say > if there is synergy between the two, but it seems like there could be. I'd > definitely recommend reading a little bit about RFC 147...I know the docs > are sparse. > > -> richard > > > Cheers, >> reto >> >> On Wed, Jul 7, 2010 at 4:54 PM, Guillaume Nodet<gno...@gmail.com> wrote: >> >> I'm not sure about the console either. I think it's more a console >>> for evaluating scala expressions. Not sure if there is any plan to >>> have commands and manage anything using this console. >>> >>> On Wed, Jul 7, 2010 at 16:39, Richard S. Hall<he...@ungoverned.org> >>> wrote: >>> >>>> On 7/7/10 3:39, Reto Bachmann-Gmuer wrote: >>>> >>>>> On Tue, Jul 6, 2010 at 11:09 PM, Richard S. >>>>> Hall<he...@ungoverned.org>wrote: >>>>> >>>>> I'm not too familiar with Scala, so pardon my ignorance. >>>>> >>>>> So is the proposal to have some sort of Scala-based console/shell? >>>>>> Does >>>>>> this mean you can do Scala-based scripting and syntax? Is this >>>>>> >>>>> something >>> >>>> that could simply be another shell front end for the Gogo runtime or is >>>>>> it >>>>>> somehow completely different? >>>>>> >>>>>> >>>>>> I must admit I'm not familiar with OSGi RFC-147 so I'm not sure if >>>>> it >>>>> could >>>>> be implemented on it. >>>>> >>>>> To be as attractive for people currently not using OSGi it should feel >>>>> >>>> as >>> >>>> much as possible like the scala console, this includes: >>>>> - autocompletion with tab >>>>> - multi-line expressions (afte an incomplete expression such as one >>>>> opening, >>>>> but not closing a bracket a continuation-prompt appears) >>>>> >>>>> Once we have this we can add a DSL to more easily do OSGi related tasks >>>>> (listing services and bundles, accessing services, etc. ) >>>>> >>>>> Well, I still can't say I totally understand what is being proposed, >>>> but >>>> >>> I'm >>> >>>> not against having people work on it at Felix if other people think its >>>> worthwhile. If it does ultimately blossom into a full-blown shell for >>>> >>> OSGi, >>> >>>> then there will certainly be some overlap with Gogo, but we can always >>>> >>> look >>> >>>> for ways to bridge the two... >>>> >>>> -> richard >>>> >>>> Reto >>>>> >>>>> >>>>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >>>
