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

[Thomas S. <th...@th...>]

It is my wish that rubydotnet is as transparent as possible and I have
succeeded if people using it think of .net classes and objects as no
different from other ruby classes and objects. Therefore I don't want to
make distinctions and namespace flattening in one hierarchy, ie. the
.net class hierarchy, and not in the other, ie. other ruby modules. 

Personally I want to be pure about this. On the other hand ruby is all
about being pragmatic and if someone prefers the namespace flattening
they should be able to choose so. Since this is all hooked up using
Module#const_missing it is trivial to support both and allow the user to
choose. We could just have a switch Object#flatten_namespace=true/false.
When the value is changed we replace the definition of const_missing to
one that does one or the other.

Performance-wise I think there are clear advantages to not using
flattening. For one thing, once a namespace or class has been looked up
once using const_missing it is instantiated into the ordinary lookup
mechanism and is everybit as fast as ruby normally is. This is not
generally possible with the flattened namespace as you would collide
with Object, String, Array, Exception, GC and maybe more.

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

It is conventional to use modules as namespaces, and the fact that
modules are more general than namespaces is not a problem it would be
worse if it was the other way around  :-)


> Could we provide ways to disambiguate things?  One that we 
> have discussed here is to say something like
> 
> 	Label = 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.

We probably could, but again I feel that we should not try to over-do
ruby. In ruby there is no ambiguity because scopes are searched in a
well-known order and the same constant cannot have different values in
the same scope.

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

Okay, I'm confused. I added the implements clause because I needed it,
not for documentation. How do you guys manage to figure out which
interfaces to implement otherwise? Do you base it which methods are
actually implemented by an object? If so I at least want to say.. wow.

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

I am an XP/Agile coder myself, though normally more pragmatic than
XP-dogmatic. All the same I like to orthogonalize early and push things
out into supporting functions, that simplify the main task I have to
accomplish. What I am promoting with ScriptingExtensions for .net is a
class library of utilities that are useful for tying scripting languages
to .net. There is probably less reuse than your framework for reuse, but
there is also more freedom and less policy. It is the difference between
a framework for interoperation vs a support library for interoperation.
It is easier to match a support library to different languages, as you
are not forced to use features that do not match your environment.

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

Agreed, it should simply be a matter of starting the interpreter
in-process and providing an interface for eval'ing/executing scripts.

I have answered somewhat selectively to keep the conversation managable.

Cheers,

Thomas