ps做的网站保存不了jpg,wordpress ftp没有权限设置,有那种做订单的网站吗,喜欢做木工 网站类型类是另外一项正被考虑引入.NET未来版本的特性。在提案“外观和扩展#xff08;Shapes and Extensions#xff09;”中#xff0c;该特性被称为外观#xff0c;它们将大幅提升.NET泛型的能力。Mads Torgersen这样描述类型类#xff1a;
接口抽象的是作为类型实例的对象…类型类是另外一项正被考虑引入.NET未来版本的特性。在提案“外观和扩展Shapes and Extensions”中该特性被称为外观它们将大幅提升.NET泛型的能力。Mads Torgersen这样描述类型类
接口抽象的是作为类型实例的对象和值的“外观shape”。从根本上讲类型类背后的思想是抽象类型本身的外观。而且当通过类型声明引入需要的类型实现一个接口时其他人可以在单独的代码中实现类型类。
类型类解决了一个长期存在的接口问题它们无法处理静态函数或操作符重载。这导致了一些问题比如在数学库中对于不同的数值数据类型需要反复声明相同的函数。
Mads总结道
一般来说外观的声明和接口声明非常像但它
几乎可以定义任意类型的成员包括静态成员
可以通过扩展实现
可以在特定的地方像类型一样使用
最后一个限制很重要外观不是类型。外观的主要目的是作为泛型的一种约束限定类型参数保证它们有正确的外观并允许泛型声明体使用那个外观。
与外观的思想紧密相关的是一种经过改进的扩展语法。扩展结构几乎可以为类型类提供任何东西而不只是方法扩展。考虑下面这个最简单的例子
public shape SNumberT
{static T operator (T t1, T t2);static T operator -(T t1, T t2);static T Zero { get; }
}
Int32类型已经提供了大部分内容但它缺少zero属性。扩展可以修复这个问题
public extension IntGroup of int : SNumberint
{public static int Zero 0;
}
然后你可以像下面这样使用它
public static AddAllT(T[] ts) where T : SNumberT // shape用作约束
{var result T.Zero; // 使用shape的Zero属性foreach (var t in ts) { result t; } //使用shape的 操作符return result;
}
实现
这实现起来需要一些接口和结构方面的技巧。
Shapes被翻译成了接口每个成员甚至是静态成员都转换成了接口中的实例成员扩展被翻译成了结构每个成员甚至是静态成员转换成了结构中的实例成员如果扩展实现了一个或多个弯管则底层的结构实现了那些外观的底层接口。
通常上述结构被称为“见证结构witness struct”。它的存在可以证明一个类遵循外观的规则。或者换句话说该类在类型类中。
编译器会将上述AddAll方法翻译成如下代码
public static T AddAllT, Impl(T[] ts) where Impl : struct, SNumberT
{var impl new Impl();var result impl.Zero;foreach (var t in ts) { result impl.op_Addition(result, t); }return result;
}
然后上述见证结构就可以用于向AddAll方法提供必要的功能。结构可以直接在类型上调用方法或者根据需要使用扩展结构。
在类和接口中实现外观
使用和我们扩展基类及实现接口一样的语法类可以显式实现一个外观。然后编译器会提供相应的见证结构。
也可以将接口标记为满足外观的要求。下面是一个例子
public extension ComparableT of IComparableT : SComparableT ;
由于IComparable和理论上的类型类之间存在一对一关系所以我们不需要为扩展结构提供扩展体。
泛型类型
事实证明泛型类型有他们自己的问题。和泛型方法一样向泛型类添加外观或者类型类作为类型约束需要额外提供一个类型参数。在泛型类上由于类型参数的数量是其名称的一部分所以这会导致它和其它名称相同的泛型类型发生冲突。
扩展外观
扩展结构不仅可以用于实现外观还可以扩展它们。因此你可以向现有的外观中添加新方法、静态方法及操作符。正如扩展方法一样语法是一样的就像它们在底层类型上直接定义了一样。
评论
总的来说人们对于该特性的反应不错。不过也有一些修改请求。例如外观目前必须显式实现。有些开发人员希望如果特定的类或接口不需要额外扩展方法时就由编译器隐式实现。Mads列举了这样做的一些问题
那可能会导致为了见证以相同的方式应用到同一类型的同一个外观而生成许多结构类型有生成的类型过度扩散的风险。如果编译器比较聪明每个程序集只生成一个或许可以缓解这种情况但我们从匿名类型了解到这种重复数据删除技术非常困难而且很容易出错。
如果我们允许泛型类型拥有外观约束的类型参数那么同一个东西拥有多个见证结构会导致实例化的泛型类型具有不同的类型标识无法互换。
人们还担心外观和扩展绑定得太紧。他们认为那将来可能会引起混淆。
对此Mads答复说
合并在我的提案里“扩展”实际上合并了多个问题
[……]
我觉得对于上述服务于所有这些目的的语言机制有太多内容需要讨论——但归根结底它们的关系非常密切。如果有一个提案可以将它们清晰地分开那将是非常有意义的。那也许会更加简单有效。
原文地址http://www.infoq.com/cn/news/2017/04/DotNet-Type-Classes .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
