Scala, OSGi and Service Management (was Re: Making sense of service binding and dependencies)

["Richard S. Hall" <he...@ungoverned.org>]

I don't know much about Scala, but definitely give it a shot. I agree 
with what you say that often we are working around limitations in Java. 
However, the big issue is getting people to venture outside what they 
already know. So, it is already a challenge getting people to try a 
Java-based DI framework, which means that a Scala-based one creates an 
extra level of challenge. But I don't think that should stop you, since 
you never know what has the potential to become popular.

I'd be interested in hearing about it.

-> richard

Ray Racine wrote:
> OFF TOPIC: Scala, OSGi and Service Managment.
>
> I'd love to see some small standard app demoing various basic usage
> scenarios with the 3-4 common service frameworks.
>
> I have the luxury of using Scala with my "Java" projects.  Scala has near
> seamless integration with Java.  And I've been successfully using Scala with
> Felix without incident for several months.
>
>  Bluntly what I see is very smart people developing creative solutions to a
> fairly simple problem made complex by the constraints of Java.
>
> So let me correct myself immediately, I'm aware that the "fairly simple
> problem" of service management is a minefield of alligators with regards to
> concurrency etc.  However as I've been reading this thread I can't help
> wondering "what would it be like" if DM were written in Scala.
>
> Here are the weapons one would bring to the fight:
>
> 1. Singleton Objects with unambiguous initialization semantics (didn't Sun
> give up on have a standard Java util global logger as they simply could not
> guarantee initialization?)
>
> 2. Traits, Scala's version of Interfaces, can contain "code" which gives you
> Mixins (clean multiple inheritance).  Take any plain ol' class and Mixin a
> few traits presto, its an OSGi service.  Clean separation.
>
> 3. Companion Objects.  Scala only provides one and only one constructor for
> a Class, but clean syntax for as many Factory Methods as one would like.
> e.g. For the Point Class.  Ctor: new Point (1,2)   FactoryMethod:  Point
> (1,2)   Factory methods look and behave like Ctors without the "new".
>
> 4. First class functions with Closures.  Factory Thunks.  Create "Builder"
> or "Constructor" thunks at runtime and give it to the framework to create
> needed services.  i.e. Functions which take no arguments but return
> instances of constructed objects initialized with values in its "closure".
>
> 5. Any Method can be reified as a function closed over the object instance.
>
> 6. All the type parametrization that Java has and much richer.
>
> 7. In Scala everything is an expression.  The "return" keyword is only used
> to break recursion.   The "Fluid" approach is standard SOP.  In Scala you
> are always chaining.  Its pretty rare to have functions and methods that
> return "nothing" which is the Scala type Unit.  Your code is fluid by
> design.
>
> 8.  Scala is OO-Functional.  Functional code is "declarative" code.
>
> 9.  Concurrency problems.  Scala has Erlang like Actors which gives you
> Message Passing Concurrency. Other approaches are supported as well.  But
> consider managing the dynamic nature of OSGi Services events as Messages to
> Actors which manage the Service Repository etc. Substantially reduced
> mucking about with mutexs, ReentrantLocks, synch blocks etc...  Safe
> concurrent code without alligators lurking to bite you in the ass down the
> road.  Scala supports immutability hence self-referential methods/functions
> which allow you to write concurrent code without ulcers.
>
> 8.  DSL capabilities.  What are the various efforts here truly all about?
> In some sense they are all alternative approaches to create a Declarative
> (DSL) Domain Specific Language for Service Management/Composition/Dependency
> etc...  Its pretty much a question of pick your favorite syntax for DSL
> implementation.
>
>  - Use XML syntax.
>  - Use Annotations.
>  - Use Cleverly named Java methods to create an API, combine with "Fluid"
> pattern or other cleverness so when you squint at it hard enough it looks
> like declarative statements for service management.
>  - Use Scala's extended syntax capabilites.
>
> Scala has some very nice capabilities of designing DSLs in Scala. For
> example,
>  - Infix and postfix Methods/Operators.
>  - Optional use of the '.' to invoke methods.  i.e. x.add (y) becomes x add
> y.  or Service X withInterface Y withImpl Z.
>
> The goal would be to use Scala syntax extensibility to define a clean
> declarative services DSL in Scala itself.
>
> As one can tell I'm a bit fired up to give this a run.  Moving forward on my
> project I see only further use of OSGi and it looks like I'm going to take a
> swag at the Felix DM translated to Scala and see how it goes.
>
> Ray
>
>
> On Wed, Feb 4, 2009 at 10:54 AM, Neil Bartlett <nj...@gmail.com> wrote:
>
>   
>> On Wed, Feb 4, 2009 at 2:52 PM, Richard S. Hall <he...@ungoverned.org>
>> wrote:
>>     
>>> Wow, it's like dueling DI frameworks!
>>>
>>> One day we will get back to our discussion of merging, but until then it
>>> would be awesome to have a page that shows back-to-back-to-back
>>>       
>> comparisons
>>     
>>> like this of DS, DM, and iPOJO.
>>>       
>> Heiko Seeberger and I will be giving a tutorial at EclipseCon in March
>> that covers exactly this subject, i.e. a comparison of component
>> frameworks for OSGi including DS, DM, iPOJO and possibly Guice. Our
>> slides and exercises will be made available under EPL shortly.
>>
>> The really cool thing is that all these frameworks interoperate
>> cleanly at the services level.
>>
>> Regards,
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>     
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Scala, OSGi and Service Management (was Re: Making sense of service binding and dependencies)

[Neil Bartlett <nj...@gmail.com>]

Ray,

There are others looking at using Scala with OSGi also, take a look at
the Scala Modules project (http://code.google.com/p/scalamodules/).

Regards,
Neil


On Fri, Feb 6, 2009 at 2:47 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> I don't know much about Scala, but definitely give it a shot. I agree with
> what you say that often we are working around limitations in Java. However,
> the big issue is getting people to venture outside what they already know.
> So, it is already a challenge getting people to try a Java-based DI
> framework, which means that a Scala-based one creates an extra level of
> challenge. But I don't think that should stop you, since you never know what
> has the potential to become popular.
>
> I'd be interested in hearing about it.
>
> -> richard
>
> Ray Racine wrote:
>>
>> OFF TOPIC: Scala, OSGi and Service Managment.
>>
>> I'd love to see some small standard app demoing various basic usage
>> scenarios with the 3-4 common service frameworks.
>>
>> I have the luxury of using Scala with my "Java" projects.  Scala has near
>> seamless integration with Java.  And I've been successfully using Scala
>> with
>> Felix without incident for several months.
>>
>>  Bluntly what I see is very smart people developing creative solutions to
>> a
>> fairly simple problem made complex by the constraints of Java.
>>
>> So let me correct myself immediately, I'm aware that the "fairly simple
>> problem" of service management is a minefield of alligators with regards
>> to
>> concurrency etc.  However as I've been reading this thread I can't help
>> wondering "what would it be like" if DM were written in Scala.
>>
>> Here are the weapons one would bring to the fight:
>>
>> 1. Singleton Objects with unambiguous initialization semantics (didn't Sun
>> give up on have a standard Java util global logger as they simply could
>> not
>> guarantee initialization?)
>>
>> 2. Traits, Scala's version of Interfaces, can contain "code" which gives
>> you
>> Mixins (clean multiple inheritance).  Take any plain ol' class and Mixin a
>> few traits presto, its an OSGi service.  Clean separation.
>>
>> 3. Companion Objects.  Scala only provides one and only one constructor
>> for
>> a Class, but clean syntax for as many Factory Methods as one would like.
>> e.g. For the Point Class.  Ctor: new Point (1,2)   FactoryMethod:  Point
>> (1,2)   Factory methods look and behave like Ctors without the "new".
>>
>> 4. First class functions with Closures.  Factory Thunks.  Create "Builder"
>> or "Constructor" thunks at runtime and give it to the framework to create
>> needed services.  i.e. Functions which take no arguments but return
>> instances of constructed objects initialized with values in its "closure".
>>
>> 5. Any Method can be reified as a function closed over the object
>> instance.
>>
>> 6. All the type parametrization that Java has and much richer.
>>
>> 7. In Scala everything is an expression.  The "return" keyword is only
>> used
>> to break recursion.   The "Fluid" approach is standard SOP.  In Scala you
>> are always chaining.  Its pretty rare to have functions and methods that
>> return "nothing" which is the Scala type Unit.  Your code is fluid by
>> design.
>>
>> 8.  Scala is OO-Functional.  Functional code is "declarative" code.
>>
>> 9.  Concurrency problems.  Scala has Erlang like Actors which gives you
>> Message Passing Concurrency. Other approaches are supported as well.  But
>> consider managing the dynamic nature of OSGi Services events as Messages
>> to
>> Actors which manage the Service Repository etc. Substantially reduced
>> mucking about with mutexs, ReentrantLocks, synch blocks etc...  Safe
>> concurrent code without alligators lurking to bite you in the ass down the
>> road.  Scala supports immutability hence self-referential
>> methods/functions
>> which allow you to write concurrent code without ulcers.
>>
>> 8.  DSL capabilities.  What are the various efforts here truly all about?
>> In some sense they are all alternative approaches to create a Declarative
>> (DSL) Domain Specific Language for Service
>> Management/Composition/Dependency
>> etc...  Its pretty much a question of pick your favorite syntax for DSL
>> implementation.
>>
>>  - Use XML syntax.
>>  - Use Annotations.
>>  - Use Cleverly named Java methods to create an API, combine with "Fluid"
>> pattern or other cleverness so when you squint at it hard enough it looks
>> like declarative statements for service management.
>>  - Use Scala's extended syntax capabilites.
>>
>> Scala has some very nice capabilities of designing DSLs in Scala. For
>> example,
>>  - Infix and postfix Methods/Operators.
>>  - Optional use of the '.' to invoke methods.  i.e. x.add (y) becomes x
>> add
>> y.  or Service X withInterface Y withImpl Z.
>>
>> The goal would be to use Scala syntax extensibility to define a clean
>> declarative services DSL in Scala itself.
>>
>> As one can tell I'm a bit fired up to give this a run.  Moving forward on
>> my
>> project I see only further use of OSGi and it looks like I'm going to take
>> a
>> swag at the Felix DM translated to Scala and see how it goes.
>>
>> Ray
>>
>>
>> On Wed, Feb 4, 2009 at 10:54 AM, Neil Bartlett <nj...@gmail.com>
>> wrote:
>>
>>
>>>
>>> On Wed, Feb 4, 2009 at 2:52 PM, Richard S. Hall <he...@ungoverned.org>
>>> wrote:
>>>
>>>>
>>>> Wow, it's like dueling DI frameworks!
>>>>
>>>> One day we will get back to our discussion of merging, but until then it
>>>> would be awesome to have a page that shows back-to-back-to-back
>>>>
>>>
>>> comparisons
>>>
>>>>
>>>> like this of DS, DM, and iPOJO.
>>>>
>>>
>>> Heiko Seeberger and I will be giving a tutorial at EclipseCon in March
>>> that covers exactly this subject, i.e. a comparison of component
>>> frameworks for OSGi including DS, DM, iPOJO and possibly Guice. Our
>>> slides and exercises will be made available under EPL shortly.
>>>
>>> The really cool thing is that all these frameworks interoperate
>>> cleanly at the services level.
>>>
>>> Regards,
>>> Neil
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org