RE: [Rubydotnet-developer] [ANN] Ruby/.NET bridge release 4 now available

[Ben S. <bsc...@pr...>]

Hi Thomas,

Thanks for your mail - sorry for the late reply.

> I think it is worth considering too. So lets talk about it=20
> and see what we can agree on.
>=20
> When I started I was aware of your project and I have=20
> attempted to factor my code so it is relatively easy to=20
> separate parts and merge into other projects. The parts that=20
> are mostly independent of my rubydotnet extension are
>=20
> 1) The type resolution system and the interface 'implements'=20
> statement is independent of .net and my rubydotnet module and=20
> would work with your extension or the java equivalent, for=20
> that matter. I know that you like the namespace "flattening"=20
> that your extension provides, but I prefer having full=20
> control and more importantly I like the fact that accessing=20
> the .net classes from ruby is completely equivalent to the=20
> way ordinary ruby classes are accessed.

I'd like to say a little more about why I like the namespace-independent
binding, discuss some objections, and comment on some ways we might be
able to provide options.  I'll discuss the "implements" clauses
separately.

We write a fair amount of C# here, and one of my least favorite things
is writing "using" statements.  It feels a bit like I am telling the
compiler something it should already know: where to find a particular
class I want to use.  I think of StreamWriter, for example, more readily
as "StreamWriter" than as "System.IO.StreamWriter", even though it is in
fact the latter.  This was also my experience when I worked with Java.

One of the things we frequently use our bridge for is exploratory work.
When I fire up irb or one of our Evaluator windows, it is nice to be
able to just start typing "ArrayList" or "DataGrid" without having to
qualify anything.  Also, for a new user, it's one thing fewer to learn
before starting to work productively.

This is similar to one reason that having global access (which our
latest releases do) is so nice: there's no need to say "start DotNet" or
"here's the DotNet instance where you can find ArrayList".

One objection to the above is that ambiguities can result.  Our
canonical example is the difference between System.Reflection.Emit.Label
and System.Windows.Forms.Label; the bridge prefers the former as a
binding for the name "Label", as it gets loaded first.  This is rare,
but annoying and confusing when it does happen.

Another objection is that it gives .NET's namespace mechanism no analog
in Ruby.  Modules seem like a natural way to provide this analog.
Namespaces do lack some features of modules, of course, like the ability
to mix in functions.

The conceptual impurity introduced by these, especially by the first, is
troubling.  Why should the name-binding rule be

	A name binds to a Ruby class first,
	then a DotNet class anywhere,
	but only the first one that is found.

When it could be

	A name binds to a Ruby class first,
	then to a DotNet class in one of the namespace-modules you've
included.

or even

	A name binds to a class in one of the modules you've included,
	whether they're DotNet ones or not?

Despite that, I still have come down lately at least slightly, and
perhaps more than that, on the pragmatic side of namespaces - preferring
the ease-of-use introduced by the flattening.  (Perhaps it is a
different aspect of simplicity.)

Could we provide ways to disambiguate things?  One that we have
discussed here is to say something like

	Label =3D System.Windows.Forms.Label

for specific cases.  Another would be for the bridge to refuse to choose
between ambiguous names itself, but rather to raise an exception when a
clash occurred.

---

I have a couple of thoughts about the "implements" clause.  One is that
I like the extra documentation: "this is an IList".  Ruby's open classes
would even make the clauses easy to add later.

However, I wonder whether requiring such a clause is in the spirit of
Ruby's dynamic, duck-typing type system.  Without requiring an
"implements" clause, any object that has the right methods can
participate as an IList, just as any Ruby object can stand in for
another.

> 2) ScriptingExtensions for .net depends on two narrow/small=20
> interfaces IObject and IProc. There is significant overlap=20
> with your code when it concerns typed delegate creation and=20
> .net interface implementation, but it is not much code and we=20
> should adopt interface and implementation to the more robust=20
> and flexible of the two, if we were to merge. I would very=20
> much like to keep all the non-ruby specific stuff in a=20
> separate project. I have joined the modules using the CVS=20
> facility for doing so, I'm sure Perforce has the same=20
> ability. I am very certain that the Lua and TCL camps and=20
> others will soon desire .net interop and we may as well share=20
> functionality that is common across all scripting languages.

I like the idea of sharing common pieces across different scripting
bridges.  Our usual practice is to design such common pieces by doing
two things, then by removing duplication, in the spirit of what an
Extreme Programmer would do.   This kind of design is given the benefit
of more experience with what is common; it also does not constrain
earlier implementations based on a supposition about what might come in
the future.

We did recently write a second client interface to our bridge, for
Squeak Smalltalk.  Squeak's object system is similar to Ruby's, which
probably made the task easier than for a system with a different feel.
We found some places in the design that needed smoothing (and there are
probably still more).  We haven't yet done an "embedding", .NET-to-Ruby
interface for Squeak, although .NET code that happened to take one of
our ClientObject instances could probably use its Call method to call
Squeak.  (This is how interface implementation is handled.)

> So my position is that I would want to keep these two aspects=20
> of my project. Next on my work agenda are
>=20
> * Embedding interface, so you can embed the ruby interpreter=20
> in a .net application. Do you all ready have an interface for=20
> embedding the interpreter without the use of sockets?
> * Mono support
> * Take a look at ruby threading on Windows
> * Ruby support in Visual Studio .net - primarily indentation=20
> and syntax highlighting.

All of these look interesting.  Regarding the first point: we don't have
that kind of interface yet.  What is missing, I think, is startup code
and the ability to ask the bridge to eval an arbitrary piece of code.
Once you have a ClientObject in hand, everything should work using the
normal callback facilities.

> The last two bullit points are not really within the scope of=20
> rubydotnet.

Agreed, but also agreed that they could be important or interesting.

---

Well, those are some of my thoughts - they might be too long.  They're
in no way the final thing I have to say on these matters; I write them
in hope of encouraging discussion.

What are your thoughts?

Regards,
Ben Schroeder