Thanks for the reply, Jeff.
ILSpy reports for "Type" (the "IL" version):
.class interface public auto ansi abstract import [relevant dll
name]
{
.custom instance void
[mscorlib]System.Runtime.InteropServices.TypeLibTypeAttribute::.ctor(int16)
= (
01 00 50 10 00 00
)
.custom instance void
[mscorlib]System.Runtime.InteropServices.GuidAttribute::.ctor(string) = (
01 00 ... (lots of numbers)
And for "function":
.method public hidebysig newslot abstract virtual
instance object marshal(idispatch) function (
[in] string marshal(bstr) Name,
[in] bool Option,
[in] [out] int32& Errors
) runtime managed internalcall
{
.custom instance void
[mscorlib]System.Runtime.InteropServices.DispIdAttribute::.ctor(int32) = (
01 00 5b 00 00 00 00 00
)
I confess this does not mean a whole lot to me, though both Type
and function are declared as abstract. Hopefully this sheds light on the
behavior in IronPython.
Thanks,
~Mike C.
-----Original Message-----
From: Jeff Hardy [mailto:jdha...@gmail.com]
Sent: Thursday, December 01, 2011 10:36 AM
To: Michael Colonno
Cc: ironpython-users@python.org
Subject: Re: [Ironpython-users] abstract class conversion?
On Thu, Dec 1, 2011 at 10:14 AM, Michael Colonno <
<mailto:mcolo...@stanford.edu> mcolo...@stanford.edu> wrote:
> In VB.NET, this works just fine:
>
>
>
> Dim A As Type
> Dim Name As String
> Dim Option As Boolean
> Dim Err As Integer
> Dim value As Object
>
> value = A.function(Name, Option, Err)
>
> In IronPython I am trying (pseudo-code):
>
> import clr
> clr.AddReferenceToFileAndPath("relevant dll") from
> API.Interop.whatever import Type
>
> A = Type()
> value = A.function("Name", True, err)
>
> Two issues / questions:
>
> 1. The IronPython code above produces: TypeError: Cannot create
> instances of Type because it is abstract. Why is an abstract Python
> class being created and do I have any control over this?
Calling `A = Type()` tries to create an instance of Type, which your VB code
doesn't do. Is `Type.function` a static method?
>
> 2. Changing the code to access the functions of Type directly (e.g.
> Type.function()) results in a "self" argument being expressed as the
> first argument in the function. i.e. the syntax expected is now
> Type.function(self, string, boolean, int). I'm familiar with "self"
> only in the context of defining class functions and not outside of a
> class definition.
It really depends on how what the signature of the function is. If it's
static, calling `Type.function` from Python shouldn't need a self argument.
Can you find the signature of `Type.function` (ILSpy is your friend here).
Feel free to elide the names; they're not really important.
- Jeff
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users
