The curiosity of the let_ property method

Question

Every .net developer knows about the concept of properties. A rough 99.99%, it's just a piece of metadata gluing together two methods, a getter, and a setter.

Same thing usually goes for events, with their add, remove, and invoke method.

The ECMA-335 describes a «Other» kind of method semantic, that would apply to either a property or an event. Conceptually, a property or an event could have a multiple number of «other» methods.

Today's the first day I stumbled upon a property with an «other» method. And of course it had to be related to COM. The interface EnvDTE.Property, in the EnvDTE assembly (used to write addins to Visual Studio), contains a property defined as follows:

.property object Value()
{
  .custom instance void [mscorlib]System.Runtime.InteropServices.DispIdAttribute::.ctor(int32) = ( 01 00 00 00 00 00 00 00 ) 
  .get instance object EnvDTE.Property::get_Value()
  .other instance void EnvDTE.Property::let_Value(object)
  .set instance void EnvDTE.Property::set_Value(object)
}

With let_Value being defined as:

.method public hidebysig newslot specialname abstract virtual 
        instance void  let_Value([in] object  marshal( struct) lppvReturn) runtime managed internalcall
{
  .custom instance void [mscorlib]System.Runtime.InteropServices.DispIdAttribute::.ctor(int32) = ( 01 00 00 00 00 00 00 00 ) 
}

Apparently, VBScript and versions of VB before VB.NET can define properties using a Let keyword. And the Let has a same signature as the Set. I sense that there's a relationship here.

But does anyone know how this property have been declared in the language that EnvDTE has been written with? How could I create an assembly with the same pattern (without using ilasm, that would be too easy)? And does anyone have faced a similar property?

And does anyone have seen other «other» properties, with maybe a different semantic than this one? And if yes, what are they used to?

Answer 1

It's a COM thing which is surfaced in VB. Set assigns a reference to replace a property's referred-to item, whereas Let is expected to copy the content of the operand into the existing property. (See also Property Get).

IIRC this is not a core COM thing, more something that's used where a language doesnt have sufficient expressive power to deal with value vs reference issues to a sufficiently precise degree - I believe it may only apply when you're using IDispatch (where you''re addressing by property id rather than method) rather than a custom interface (where you always have to resolve to a method and call that). I'm pretty sure VB.NET (or other .NET languages) doesnt surface such things and hence they're a rare thing.

Essential COM by Box doesnt mention it (only propget and propput for get and set). COM IDL & Interface Design by Dr Al Major mentions it on P106 ans says:

dispinterface DMyInterface { methods:
...
[id(3), propputref] void lMyProp([in] IDispatch *pDisp);
}

The propputref attribute is an odd little thign that has its origins in the idiosynracies of Visual Basic syntax. Consider the following:

Dim val as DMyOtherInterface
Dim var as DMyInterface

Set var.lMyProp = val
var.lMyProp = val

The two assignments are both permissible but mean completely different things. The use of the Set keyword in the first assginment indicates that lMyProp is being assigned an interface [...]. The second assignment is a simpe one, where the value of the val object, which is the value of the default member of the DMyOtherInterface interface (the default member is the member tagged by the DISPID_VALUE ID, as will be explained shortly), is being assigned to the lMyProp property of the DMyInterface interface.

The first assignment is carried out using the propputref method associated with the lMyProp property, while the second assignment uses the propput method. In order for this to work, both the propputref and propput methods must be defined. If you're confused by this way of doing things, you're not alone. While VB has many good features that have fundamentally changed the nature of programming, the definition of the language was predominantly market-driven rather than being designed, and sometimes it shows.

Amusingly I havent ever used the Major book since reading it in early 2000 before the COM and .COM bust (Its a good book for its purpose though). Thanks for the trip down memory lane - I love the way people tell us that programming keeps getting harder!

Dont have the Lidin book with me to see if it mentions .other but I'm sure you do (BTW thanks a lot for Mono.Cecil)

Answer 2

Visual Studio automation is based upon COM. The property in question has probably been generated via a tool to support COM Interop (tlbimp potential). I doubt anyone coded this in an actual .Net based language.