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

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

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

True. But think of it this way. I want to say to the ruby developer that
knows the .net framework. Just do what you would do if you thought the
.net framework was actually implemented in ruby. I am pretty sure that
people would expect the namespace hierarchy to be conserved and modules
are the namespaces in ruby - they also do other things, but they *are*
the namespaces of ruby.

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

I would probably use it in irb, but not in a script. I would be
indifferent to the default value.

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

Of course you are right. I was just thinking that resolving classes
using constants would be the fastest possible way, but it is probably
implemented with a hash by ruby :-)

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

In C#? Yes sure, if there is an ambiguity you have to used the fully
qualified form. In ruby the ambiguity cannot exist. The same constant
can only reference one type in a given scope. The "innermost" constant
wins when the scopes are searched outwards for the constant. At least
thats how I understand it.

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

Nothing. Things will fail nicely at runtime, as we are used to in ruby.
If I understand you correctly you are determining the interface at
binding time when a .net method is invoked from ruby. What if I want to
fill up an ArrayList of IKeyMaps (I made that up). I mean, the
conversion can only happen at the boundary between ruby and .net, so
what if you have to go indirectly via something like a list of Objects?

But I think it might be a cool idea all the same. I'll have to digest
it, but it could be good :-)

Now that I'm caving in to your design decisions :-) ... I'd like to know
how the other people on this list feels about the namespace flattening
feature. Is it what we want for ruby with .net? Why is it that we want
this with ruby, when the .net folks to great measures to make the
hierarchy?

Be honest, but not brutal :-)

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

Probably not. I know a bit of Python and Perl and next to nothing about
Lua and Tcl. What I do know is that services such as generation of
managed interfaces and delegates that forward to a dynamic object can be
implemented based on two extremely generic interfaces:

namespace ScriptingExtensions {

	public interface IObject {
		object send(string message, object[] args);
	}

	public interface IProc {
		object call(object[] args);
	}
}

Designing for multiple languages or not, I want to keep stuff as
orthogonal as possible for my own sake. Similarly the basic support for
writing C# and VB from inside the scripting languages is easy to factor
out too. I'm not saying that you should always do it, but when it is
down-right obvious it is worth doing even if you don't ever reuse the
code for another language.

I am going to diverge from rubydotnet pretty soon. I will probably do
Mono support and an optimization that keeps week references to proxies
to avoid creating them over and over and then I'll take a look at
something else. What I'm saying is that the duplication of effort will
stop pretty soon, anyway.

I have discovered that there is going to be a presentation about ruby
and Visual Studio .net 2003 at RubyConf. Are any of you guys going?
Anyway, I have been thinking about adding editor support to visual
studio .net 2003 my self, but maybe I wont have to. I think this is
quite exciting as my fingers always gets confused when I jump between
ruby/emacs and C#/C++/Visual Studio. So if ruby threading could just be
worked out ruby would really be shining on Windows!