Binsor Component forwarding

[Ayende Rahien]

Hi guys,
I recently added the ability to handle component forwarding (think about it as one component that handles several interfaces) to Windsor.
I am trying to think how to handle this with Binsor.
Right now I have this:

import Rhino.Commons.Test.Components
import Rhino.Commons.Test.Binsor from Rhino.Commons.Test

for type in AllTypes("Rhino.Commons.NHibernate") \
    .Where({ t as System.Type | t.Name.Contains("NHRepository") }):
    component "nh.repos", type.GetFirstInterface(), type

component 'FubarRepository', IFubarRepository, FubarRepository

Kernel.RegisterHandlerForwarding(IRepository of Fubar, 'FubarRepository')

This just make a direct call to the kernel using its API.
This works, but I wonder if there is a better syntax for this.

[Ernst Naezer]

what about;

forward IRepository of Fubar to 'FubarRepository'

forward component IRepository of Fubar to 'FubarRepository'

ernst

[Ayende Rahien]

not valid boo code :-(

[Ernst Naezer]

hmmm. too bad :(

and without the 'to' ?

[Ayende Rahien]

forward IRepository of Fubar, 'FubarRepository'

This is legal.
Is this readable?

[Ernst Naezer]

what about the notation the simple state machine project uses?

forward IRepository of Fubar >> 'FubarRepository'

[Craig Neuwirt]

or using our component references

forward IRepository of Fubar >> @FubarRepository

[Ayende Rahien]

I like this!

[Craig Neuwirt]

I'll add it to binsor

[Ernst Naezer]

cool!

[neil.bo...@gmail.com]

That looks great, guys! Can't wait to use it.

[Craig Neuwirt]

Ok, here is the new syntax I came up with (old syntax still available). 
Besides supported multiple service interfaces, it is clear which is the name, implementation and services.

component FakeRepository of Fubar < IRepository of Fubar
or
component "fubar" is FubarRepository < IFubarRepository, IRepository of Fubar

extend "fubar" < FakeRepository of Fubar
or
extend @fubar < FakeRepository of Fubar

cheers,
  craig

[Ayende Rahien]

Cool.
I think it is time to create Binsor syntax page in the wiki.

As an aside, I recently had to deal with complex configuration using Binsor, and it occurred to me that we can do more about that.

Imagine:

facility NServiceBusFacility_Binsor:
    serializationFormat = SerializationFormat.Binary
    transport = Transport (
        InputQueue: MyConfiguration.InputQueue,
        ErrorQueue: MyConfiguration.ErrorQueue
    )
    subsciptionQueue = MyConfiguration.SubscriptionsQueue
    bus = UnicastBus (
            MessageOwners : {
                "Messages" : "messagebus"
            },
            MessageHandlerAssemblies : ( Assembly.Load("Server"), )
    )

I don't like this, too much syntax. I would like to have this:

facility NServiceBusFacility_Binsor:
    serializationFormat = SerializationFormat.Binary
    transport:
        InputQueue = MyConfiguration.InputQueue,
        ErrorQueue = MyConfiguration.ErrorQueue
   
    subsciptionQueue = MyConfiguration.SubscriptionsQueue
    bus:
        MessageOwners = { "Messages" : "messagebus" }
        MessageHandlerAssemblies = ( Assembly.Load("Server"), )

[Craig Neuwirt]

On Thu, Jul 10, 2008 at 8:20 AM, Ayende Rahien <aye...@ayende.com> wrote:

Cool.
I think it is time to create Binsor syntax page in the wiki.

Yeah, I totally agree.  The last committ unified Binsor with the ComponentRegistration stuff so we will easily be able to support all features.  I am going to add activators, proxies, interceptors, mixins,... shortly
 

Yeah, some of the new transformer ideas will fit nicely in Binsor.
 

NServiceBusFacility, how nice!!!!!   

[Ernst Naezer]

very cool stuff indeed!

[Nathan Stott]

BlockToArgumentTransformer should help with that. I just committed
enhancements to the originally and badly named
MacroBlockToParametersTransformer as BlockToArgumentTransformer.

[Ayende Rahien]

Nathan,
Can you take a peek at the Binsor implementation and see if there are thinks that can be implemented in Rhino DSL instead?

[Nathan Stott]

Sure thing. I'll put it in my queue.

[Nathan Stott]

I've looked through Binsor and the things that I've been doing with
Boo and DSL are different from the approach taken by Binsor. I've
made heavier use of the 'base class' methods and transformers to
define my DSL whereas Binsor makes heavy use of AstMacros.

Fundamentally, I believe the two approaches can provide the same
functionality. That's the beauty of Boo isnt it? Extreme
flexibility.

The way that the AbstractBinsorMacro class is defined mimics the way
that the Boo transformers work in that it provides overridable
hook-ins for subclasses.

I'm not sure if anything I've done so far can be directly applied to
Binsor, though I do intend to study the code more this weekend and
perhaps I'll see something that I haven't seen yet.

Also, I believe that the syntax you proposed earlier in this thread
looks great and is readily achievable.

[Craig Neuwirt]

Hi Nathan,

 Thanks for reviewing Binsor.  You are right about the different approaches.
Binsor kinda came before the Rhino.DSL project so it never made strong use
of the ImplicitBaseClass.  If I were to take that approach more, would it make
things easier and more flexible with respect to the kind of syntax Ayende is
look for?

cheers,
 craig

[Nathan Stott]

Craig, I believe there are several advantages to taking advantage of
the base class to define the DSL.

First, it is more self-documenting. A programmer can look at just the
base class and learn a lot about the DSL.

Second, making use of transformers to alter statements in order to fit
base class method calls is a more flexible cross-cutting approach.
Any DSL that uses a base class can also make use of these
transformers, hence more code reusability.

Last, and perhaps least important but still interesting, other
languages can be used with the DSL. A C# implementer could inherit
from the base class and make use of the methods. I'm supporting this
approach in Mite as an alternative for those who don't want to learn
Boo or who just must have intellisense.

[Ayende Rahien]

The last one is important, Rhino ETL started as very similar to the way Binsor is right now.
I had some issues getting my devs to work in Boo ( no IDE, mostly ).
When I re-wrote it the third time, I used the base class approach, and made sure that it was possible to use from C#.
It brought a lot more acceptance from the devs, to start with, but also meant that the code for the DSL was generally much simpler.

[Craig Neuwirt]

They say the third time is a charm; Binsor 3.0

[Nathan Stott]

Craig, I want to help with Binsor 3.0. Let me know what I can do.

[Craig Neuwirt]

Hi Nathan,

  Any help you could provide is welcomed and greatly appreciated.  Since you have done a great job applying the Rhino.DSL idioms already, it would be very helpful to get an initial implict base class started and possible apply one of the transformers to achieve the an existing binsor syntax.  We could then start filling in with the remaining syntax.  Of course any improved syntax is welcome too.

cheers,
craig