Interest in .Net connectivity?

[Michael Latta]

I am looking at building an interop set for .Net classes. The idea would be
to make it at least as easy as hte existing COM interop. Smalltalk makes it
so much easier to interop with other object models! The idea would be to
host the CLR within the Dolphin Smalltalk process. In the long run I would
like to have both the WCF communications facility and the WPF UI features
more integrated into Dolphin. I would probably work on basic interop first,
then WPF, and last WCF. Let me know how much interest there is in this.

I would expect to make this a commerial library for a nominal fee.

Michael

[Steve Alan Waring]

Hi Michael,

I am very interested. I have watched a couple of talks on
WPF/WinFX/Avalon and it looks interesting.

I don't want to put words in Blair's mouth, but his response in the
"The Dolphin Development Roadmap" thread indicates that they are
looking at .NET interop. I would expect, (or at least hope) that this
will be in D7.

> I would expect to make this a commerial library for a nominal fee.

I am not sure what you mean by a nominal fee, but if you did this, I
would happily pay $50-100 if only to see what you have done and for the
opportunity to start playing with it in Dolphin.

Cheering you on!
Steve

[Andreas Wacknitz]

In this price range you can count me as a future customer, too.

Andreas

[Chris Uppal]

Michael Latta wrote:

> I am looking at building an interop set for .Net classes. The idea would
> be to make it at least as easy as hte existing COM interop. Smalltalk
> makes it so much easier to interop with other object models! The idea
> would be to host the CLR within the Dolphin Smalltalk process.

I've thought a few times about doing something similar myself (mostly as a way
of getting some real knowledge of "deep" CLR) basing it on the approach to
embeding the JVM that I've taken with JNIPort. Since the two architectures
seem to be very similar, and I would assume that roughly the same set of
problems and opportunities would arise, you may find it worthwhile to take a
look at my stuff. In particular the use of light-weight, transiently
generated, wrapper classes ("ghost classes").

FWIW, Blair recently said that he's dissatisfied with the DNO-based processing
in the COM stuff, and seems to think that transient wrapper classes would have
worked better.

(BTW, I probably wouldn't be interested in buying such a feature myself --
although one never knows what the future holds...)

-- chris

[Dan Antion]

This is certainly a feature I will be willing to purchase.

Dan Antion

[Michael Latta]

Thanks for the pointer to your Java interface. I may find that useful as
well.

When you suggest using dynamically created wrapper classes I can see the
value for efficiency sake, and as you describe the image stripping issue.
But, it would also mean that the user would get no help from code assist or
even have an artifact to reference in a browser. Have you found this to be
an issue in using your software? I found it useful to be able to view a
Smalltalk class for each COM type that was imported.

Where do you resolve the overloaded method dispatch issue? Does the
smalltalk wrapper class decide which Java method to invoke, or do you do
that in the Java space?

Michael

"Chris Uppal" <chris...@metagnostic.REMOVE-THIS.org> wrote in message
news:4466f14b$0$643$bed6...@news.gradwell.net...

[esta...@cgpaint.com]

Michael,

I would definitely be interested in this. I posted the "Dolphin
Development Roadmap" article with a question about .NET interop.

You'd have me as a customer, and your nominal fee would be most
agreeable.

Eric

[Christoph J. Bachinger]

Dan Antion schrieb:

I agree.

cjb

[Chris Uppal]

Michael,

> When you suggest using dynamically created wrapper classes I can see the
> value for efficiency sake, and as you describe the image stripping issue.
> But, it would also mean that the user would get no help from code assist
> or even have an artifact to reference in a browser.

It depends on how you handle it. Yes, if everything is done dynamically then
code-assist, etc, can't get a look-in.

But it isn't an either-or choice between statically- and dynamically-generated
wrappers. In the scheme I use, you can generate wrappers statically if you
want (I often do), and /also/ ask for dynamic wrappers to be generated at
runtime. The system will then ensure that the dynamically-generated wrapper
for a given Java class is a subclass of the most specific available static
wrapper for the same class. That gets (IMO) the best of both worlds, since the
more efficient dynamically-generated wrapper methods override the static ones
(they have the same names by design). So you can code against the static
wrappers, but run against the dynamic ones.

The hybrid approach also means that any classes/methods for which you haven't
generated wrappers (and in Java you often end up looking at instances of
private and/or nested and/or anonymous classes which you didn't even know
existed) get wrapped automatically.

Incidentally, that approach is usually a good thing, but does have downsides
too. In Java it's quite common to declare the return type of a method to be an
interface, but when JNIPort sees the object, it will use the wrapper for the
concrete class of the object. That is usually exactly what you want, but comes
a bit unstuck if you have added Smalltalk extensions to the wrapper for that
interface rather than the concrete type -- since the proxy object isn't an
instance of that wrapper class, it doesn't pick up the extensions. The /best/
way to cure that would be to add Mixins to Smalltalk. But, in the absence
thereof, I have a workaround which does work, but is not particularly
satisfactory. You have to send an explicit #asA: message to the proxy to get
/another/ proxy which is an instance of the wrapper for the interface.

> Have you found this
> to be an issue in using your software?

Yes and no. I have found it worthwhile to make the JNIPort status monitor
application display all the runtime Java classes it knows about in a
sort-of-browsable way. You can see all the known classes and their wrapper
methods. That pane also can launch a web browser on the JavaDoc for a class
(if it's configured correctly). It also allows you to drag wrapper class and
method names into workspaces to save typing. (JNIPort was, and is, Dolphin 5
code so code completion isn't available at all. When I move to D6 I /may/ find
it worthwhile to extend the system's code-completion so that it "knows" about
dynamic Java stuff too.) So, yes, I have found it enough of a problem to be
worth creating workarounds for.

> I found it useful to be able to
> view a Smalltalk class for each COM type that was imported.

As above, you can see the stuff that has been imported in the Status Monitor,
and that gives you the same information as looking at statically-generated
wrappers would. The real reason (IMO) for generating static wrappers is to be
able to add "normal" Smalltalk methods to them. But I must admit that
another reason is to avoid 'Message not defined' warnings from the IDE ;-)

> Where do you resolve the overloaded method dispatch issue? Does the
> smalltalk wrapper class decide which Java method to invoke, or do you do
> that in the Java space?

Neither ;-) I take a completely different approach. In my view, the "name" of
a Java method includes its signature and type (because that's how the JVM[*] is
defined), and from that viewpoint Java doesn't have method overloading at all.
So, conceptually, each wrapper method name corresponds to the /complete/ name,
signature, and type of the corresponding Java method. In practise, I use some
fairly aggressive heuristics to cut down on the verbiage, but it is still the
case that every argument's keyword is derived from the name of the
corresponding type. For instance the static methods java.Math.ulp(float) and
java.Math.ulp(double) are turned into Smalltalk methods (on the object
corresponding to that Java class) #ulp_float: and #ulp_double:. I extend that
to zero-argument methods by using "_null", so the method java.Math.random() is
wrapped by #random_null. That has the huge advantage of avoiding name clashes
with inherited Smalltalk methods like #size and #copy.

Another few of examples (you can probably guess that I'm pretty proud of this
idea ;-)

java.lang.String.charAt(int) <=> #charAt_int:
java.lang.String.compareTo(String) <=> #compareTo_String:
java.lang.String.indexOf(String, int) <=> #indexOf_String:int:

The constructor: String(byte[], int, int) is wrapped as
#new_byteArray:int:int:. The no-parameter constructor is wrapped as #new_null.

The static field java.lang.String.CASE_INSENSITIVE_COLOR is wrapped as a
"getter" method called #get_CASE_INSENSITIVE_COLOR.

And so on....

Ultimately it means that "overloaded" method resolution is done by the
programmer rather than by the system. IMO that's a better compromise than
having a bunch of hidden runtime heuristics to contend with. It also produces
not-too-unreasonable (to this Smalltalker's eyes) method names while completely
avoiding name clashes.

-- chris

([*] Although I usually talk about "Java", JNIPort really has nothing to do
with that language -- JNIPort actually works with a /JVM/ and the classes,
objects, and methods which that JVM knows about, and it "thinks" in terms of
JVM semantics. It's roughly the same distinction as between C# and the CLR.)

[Michael Latta]

Thanks for your insights. I am sure they will help in the design of my
project.

Michael

"Chris Uppal" <chris...@metagnostic.REMOVE-THIS.org> wrote in message

news:44686c7e$0$637$bed6...@news.gradwell.net...