Interest in .Net connectivity?

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

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

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

> 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.  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
>>
>>
> This is certainly a feature I will be willing to purchase.

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