let_ property方法的好奇心

Question

每个.net开发人员都知道属性的概念.粗略的99.99%,它只是一个元数据粘合在一起的两个方法,一个吸气剂和一个设定器.

通常使用add,remove和invoke方法对事件也是如此.

ECMA-335描述了一种"其他"方法语义,适用于属性或事件.从概念上讲,财产或事件可能有多种"其他"方法.

今天是我用"其他"方法偶然发现房产的第一天.当然,它必须与COM有关.EnvDTE程序集中的EnvDTE.Property接口(用于向Visual Studio编写插件)包含一个定义如下的属性:

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

将let_Value定义为:

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

显然,VB.NET之前的VBScript和VB版本可以使用Let关键字定义属性.并且Let与Set具有相同的签名.我觉得这里有关系.

但有没有人知道这个属性是如何用EnvDTE编写的语言声明的？我怎么能用相同的模式创建一个程序集(不使用ilasm,这太容易了)？还有人遇到类似的财产吗？

有没有人见过其他"其他"属性,可能与这个属性有不同的语义？如果是的话,他们习惯了什么？

Answer 1

这是一个在VB中出现的COM事物.Set指定一个引用来替换一个属性的引用项,而Let则希望将操作数的内容复制到现有属性中.(另见Property Get).

IIRC这不是一个核心的COM事物,更多的东西用于语言没有足够的表达能力来处理价值与参考问题到足够精确的程度 - 我相信它可能只适用于你使用IDispatch(你在哪里) '通过属性id而不是方法进行寻址)而不是自定义接口(您总是必须解析为方法并调用它).我很确定VB.NET(或其他.NET语言)不会出现这样的事情,因此它们是罕见的.

基本的COM by Box没有提到它(只有get和set的propget和propput).Al Major博士的COM IDL和界面设计在P106上提及它说:

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

该propputref属性是一个奇怪的小东西,起源于Visual Basic语法的特性.考虑以下:

Dim val as DMyOtherInterface
Dim var as DMyInterface

Set var.lMyProp = val
var.lMyProp = val

这两项任务都是允许的,但意味着完全不同的事情.Set在第一个分类中使用关键字表示为lMyProp分配了一个接口[...].第二分配是simpe一个,其中该值的的val对象,这是默认的成员的值DMyOtherInterface界面(默认构件是由标记的部件DISPID_VALUEID,这将在稍后解释)时,被分配给界面的lMyProp属性DMyInterface.

第一个赋值使用与lMyProp属性关联的propputref方法执行,而第二个赋值使用propput方法.为了使其工作,必须定义propputref 和 propput方法.如果你对这种做事方式感到困惑,那么你并不孤单.虽然VB有许多好的功能从根本上改变了编程的本质,但语言的定义主要是市场驱动而不是设计,有时它表明.

有趣的是,自从2000年初在COM和.COM破坏之前阅读它以来,我从未使用过大本书(尽管它是一本很好的书).感谢记忆之旅 - 我喜欢人们告诉我们编程越来越难的方式!

没有Lidin书和我一起看看它是否提到.other但是我确定你这样做(BTW非常感谢Mono.Cecil)