没有名字的反思 [英] Reflection WITHOUT Names
问题描述
Xy + Andrew写道：
"使用运行时指令，您可以通过指定应用程序反映的类型和成员来微调我们的编译器选择。"
非常棒。 我们是否还可以指示它包含类型/成员但没有名称？
通常在反射场景中，我们需要包含变量/参数类型信息（例如参数类型），但我们不需要方法名称或参数名称等。
根据实际情况，名称可以为空白，也可以替换为尽可能短的唯一半随机字母数字标识符。
我建议使用一个指令，当文字字符串（在C＃源代码中）包含反射类型的名称时，.NET Native可以确定地知道或会员。
这将允许.NET Native用缩短的标识符字符串替换字符串。
Frex考虑到这一点：
System.Type t = ...;
PropertyInfo pi = t.GetProperty（" MyTestProperty"）;
使用指令，它可能看起来像这个：
[ReflectionMemberName]
私人const字符串kNameOf_MyTestProperty =" MyTestProperty";
System.Type t = ...;
PropertyInfo pi = t.GetProperty（kNameOf_MyTestProperty）;
在该指令的帮助下，.NET Native将是能够替换字符串"MyTestProperty"使用新的缩写名称，例如"p1"。
否则，如果您没有该指令，那么.NET Native就不会确定该字符串是否真的是一个成员的名字，或者恰巧是巧合等于一个成员的名字。
使用该指令，.NET Native可以用缩写的名称替换所有出现的成员名称。
<如果你想更积极地进行优化，.NET Native可以用一个新的方法调用替换整个GetProperty（字符串）方法调用，该方法调用通过整数ID（例如MetadataToken或类似代码）而不是name / string来检索PropertyInfo，从而完全
消除名称而不是缩短名称。
我还建议获得System.Type或MemberInfo对象通过GUID（参见现有的System.Type.GUID属性）而不是通过名称。
您可以制定一个指令，允许我们指定用于特定类型的特定GUID。
- 有关其他主题的其他建议： -
如果.NET Native通过生成VC ++或C ++ / CLI或C ++ / CX源代码（来自原始C＃或CIL）来工作，那么我认为.NET Native应该有一个选项来显示/提供生成的C ++源代码，以便进行故障排除，调试，
理解和分析目的。
问题：System.Linq.Expressions.LambdaExpression.Compile（）继续得到支持？
这在某些情况下非常有用。
WCF确实应该得到支持，但我认为没关系支持WCF需要在源代码中添加一些指令或属性。
我个人认为不值得支持过时的x86- 32架构。
人们应该使用x86-64（x64），因为它具有主要的性能优势，例如可用寄存器的两倍。
x86-64的设计*不仅仅是关于添加64位指针支持。
它还清理了x86-32并解决了x86-32中的一些主要缺陷，例如寄存器不足。
我建议在所有新计算机上安装64位Windows，即使它们的RAM少于4GB。
x86-64是比x86-32更清洁，速度更快的架构，最后一台x86-32 CPU在几年前停止生产。
显然，我们很多人都希望.NET Native支持桌面和服务器应用，而不仅仅是Windows Store应用。
对不起，我们很抱歉。 我的消息在MS Word中看起来很好，但在复制粘贴到论坛时却没有。
这些是一些有趣的想法 - 感谢您的反馈！ &NBSP;&NBSP;我们还没有考虑删除或缩短名称，我很想知道你对这个功能的动机是什么？ 是为了节省大小，还是仅仅为了混淆
的原因？
.NET Native不生成C ++源代码 - 它从IL转到MDIL（主要是机器代码，但是一些伪操作适用于报告GC位置的事情，然后从MDIL到机器代码。我们确实使用C ++编译器的后端来生成
MDIL，但是我们已经设置了一个自定义前端，它从构建.NET应用程序生成的MSIL二进制文件中提供代码生成器信息。
.NET Native配置文件支持.NET Core配置文件中支持的所有API（它只是.NET上的优化步骤），尽管我们在.NET Native中实现了不同的表达式树 - - 在运行时我们使用解释器而不是编译器。
WCF肯定是我们知道需要支持的库之一，事实上我们正积极致力于实现WCF在.NET Native上启动并运行。
对于32位x86和64位x86，我们支持这两种架构。 支持32位架构的主要原因之一是许多平板电脑仅运行32位芯片（例如戴尔Venue Pro）。这些机器需要32位x86程序
- 而且由于64位计算机也运行32位程序，我们发现许多应用程序确实使用32位x86目标以获得更广泛的覆盖范围。
Xy+Andrew wrote:
"Using Runtime Directives, you can fine-tune our compiler’s choices by specifying what types and members your app reflects on."
That is excellent. Can we also instruct it to include a type/member but WITHOUT the names? Often in reflection scenarios, we need the variable/parameter type information included (such as parameter types) but we don't need the method name or parameter names, etc.
Depending on what works in practise, the names could be either blank OR replaced by the shortest-possible unique semi-random alphanumeric identifier.
I suggest a directive that gives .NET Native the power to know with certainty when a literal string (in C# source code) contains the name of a reflection type or member. This would allow .NET Native to replace the string with the shortened identifier-string. Frex consider this:
System.Type t = ...;
PropertyInfo pi = t.GetProperty("MyTestProperty");
With a directive, it might look something like this:
[ReflectionMemberName]
private const string kNameOf_MyTestProperty = "MyTestProperty";
System.Type t = ...;
PropertyInfo pi = t.GetProperty(kNameOf_MyTestProperty);
With the help of that directive, .NET Native would be able to replace the string "MyTestProperty" with the new shortened name of the property such as "p1".
Otherwise, if you don't have the directive, then .NET Native wouldn't know for sure whether the string is truly the name of a member or just happens by coincidence to equal the name of a member. With the directive, .NET Native can replace all occurrences of the member name with the shortened name.
If you want to optimize more aggressively, .NET Native could replace the entire GetProperty(string) method call with a new method call that retrieves the PropertyInfo via an integer ID (such as MetadataToken or similar) instead of name/string, thereby totally eliminating the names instead of shortening the names.
I also suggest the ability to obtain a System.Type or MemberInfo object via GUID (see existing System.Type.GUID property) instead of via name. You might make a directive that allows us to specify a particular GUID to be used for a particular type.
-- Other suggestions on other topics: --
If .NET Native works by generating VC++ or C++/CLI or C++/CX source code (from original C# or CIL), then I think .NET Native should have an option to show/give us the generated C++ source code, for troubleshooting, debugging, understanding, and analysis purposes.
Question: Will System.Linq.Expressions.LambdaExpression.Compile() continue to be supported? It's quite useful in certain situations.
WCF really should be supported but I think it's OK if supporting WCF requires adding some directives or attributes to the source code.
Personally I don't think it's worthwhile supporting the obsolete x86-32 architecture. People should be using x86-64 (x64) because it has major performance advantages such as twice as many available registers. The design of x86-64 was *not* only about adding 64-bit pointer support. It also cleaned up x86-32 and tackled some major deficiencies in x86-32 such as insufficient registers. I recommend installing 64-bit Windows on all new computers even if they have less than 4GB of RAM. x86-64 is a cleaner and faster architecture than x86-32 and the last x86-32 CPU stopped production years ago.
Obviously many of us hope that .NET Native will support desktop and server apps, not only Windows Store apps.
Sorry for the spacing. My message looks fine in MS Word but not when copy-pasted to the forum.
These are some interesting ideas for sure - thanks for the feedback! We haven't looked into removing or shortening names, I'd be curious as to what your motivation would be for such a feature? Is it for size savings, or simply for obfuscation reasons?
.NET Native does not produce C++ source code - it goes from IL to MDIL (mostly machine code, but with some pseudo-ops in place for things like reporting GC locations) and then from MDIL to machine code. We do use the C++ compiler's back end to produce the MDIL, but we've put on a custom front end which feeds the code generator information from the MSIL binary that was produced from building the .NET Application.
All APIs that are supported in the .NET Core profile are supported in .NET Native (it's simply an optimization step on top of .NET), although we do implement expression trees differently in .NET Native -- at runtime we use an interpreter rather than a compiler.
WCF is definitely one of the libraries that we know we need to support, and in fact we're actively working on getting an implementation of WCF up and running on .NET Native.
As for 32 bit x86 vs 64 bit x86, we do support both architectures. One of the main reasons for supporting the 32 bit architecture is that many tablets run on 32 bit only chips (for instance the Dell Venue Pro). Those machines need 32 bit x86 programs - and since 64 bit computers run 32 bit programs as well, we find that a lot of applications do use the 32 bit x86 target in order to get broader reach.
这篇关于没有名字的反思的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
