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

[John R. P. <jo...@pi...>]

On Fri, 26 Sep 2003 18:32:06 +0200, "Thomas Sondergaard" wrote:

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

Agreed...we actually want to make the bridge transparent as well.  What doesn't
seem clear to me is that transparency is somehow lost or less if we flatten
namespaces.  After all, namespaces in .NET and Ruby modules are not exactly one
to one.

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

We could do this, as you say, very easily, but I suspect you would not agree
with our choice of default value (flatten_namespace = true)!  By the way, if we
provided the option, who would prefer to not flatten the namespaces?

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

I don't see how flattening a namespace prevents peformance optimizations. What
makes you think you can't look up the constant once then keep a hash or define a
new global in either approach?

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

I have yet to find it anything but natural to type the following code at the top
of every C# file:

using System;
using System.Collection;

It always gets me! Gosh -- I've even heard of IDE's on the market that
automatically include using statements -- what a nice idea! So then, why do
language inventors make us do this anyways?

> 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  :-)

Agreed, but do we always have to be so pure?  I just like to be able to type
programs in real fast that work with POLS (principle of least surprise). I am
always shocked when the C# compiler tells me it doesn't know who ArrayList is
when I just got done using it every else in the program. Silly compiler!
 
> 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.

So do you know what happens if you include System.Reflection.Emit and
System.Windows.Forms?  What does Label resolve to?  Is an ambiguity introduced
manually less ambiguous than an ambiguity introduced automatically?

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

Maybe you'd be disappointed if we told you. It's actually worse than that! We
take the programmers word for it! If you try to use a Ruby object as IDisposable
then we just build the interface wrapper and give it a whirl. What could go
wrong?

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

But until I know the features in those other environments that might not work,
it seems way too speculative for us to design for them.  You might be more
familiar with those other languages than us -- so we'd value your input!
 
Regards,

John