• 一个茴字有三种写法——吐槽C#9.0的Records


    最近是微软开了Build 2020大会,由于疫情原因,改成了在线举行,Build大会上,C#公布9.0版本。

    我个人对于C#的更新向来都是喜闻乐见,乐于接受的,对于博客园上某些人天天嘲讽C#只会增加语法糖的人,我向来对他们不屑一顾,认为他们是井底之蛙。

    因此我仔细看了微软发的文章Welcome to C# 9.0,准备好好观摩和学习。但当我看到Records语法时,我就隐隐感觉C#这样玩语法糖要翻车了。

    后来看到知乎上的问题如何评价即将发布的 C# 9.0?,我稍加思索,愈发觉得Records语法完全是大型翻车现场,因此整理出来我认为的Records的翻车点(兼吐槽)。

    首先看官方给出的Records样例

    public data class Person
    {
        public string FirstName { get; init; }
        public string LastName { get; init; }
    }
    

    第一个吐槽点:data class声明有必要吗?如果要多加一个data关键字,直接用record不好吗,如果不加关键字,为什么不用readonly class啊。

    public record Person {}
    public readonly class Person {} 
    

    第二个吐槽点,官方给出上面的等价定义

    public data class Person { string FirstName; string LastName; }
    

    看到这里我几乎晕了过去,确定这两者等价吗?语言的一致性破坏的损失殆尽?不信?如果把data这个词去掉的话。

    public class Person
    {
        public string FirstName { get; init; }
        public string LastName { get; init; }
    }
    public class Person
    {
        string FirstName; 
        string LastName;
    }
    

    但凡任何一个C#初学者,都不会说上面等价,因为那段定义等于

    public class Person
    {
        public string FirstName { get; init; }
        public string LastName { get; init; }
    }
    public class Person
    {
        private string FirstName { get; set; }; 
        private string LastName { get; set; };
    }
    

    这怎么等价?也就是说,加了data一个关键词,后面我们对C#语法的掌握就要被推翻?!

    Ok,上面喷完了,我们再来看看官方还有第3种定义方法

    public data class Person(string FirstName, string LastName);
    

    这种record定义非常漂亮。但,一个record有3种定义方法?!你说之前的LINQ有2种写法,我认了,毕竟看起来更加简单直观,更像sql。但record是现代版的一个茴字有3种写法啊!

    总结,这次Records语法,看起来漂亮,实际上是一场巨大的灾难。归根结底在于对于Records的定位不够清晰。如果要真正的Immutable,那么Records应该是类似Tuple的存在,应该和Class切割开,走类似Rust的Stuct的路子,加上UnionType,EnumClass就是起飞。如果想要一个看起来Immutable实际上是Mutable的Class的话,还不如想想怎么简化Class语法,但要注意简化的过程中要保持一致性。什么?你要Mutable?不就是Class嘛。

    下面是一些碎碎念时间。

    自从C#之父Anders去做Typescript之后,能看出C#团队还是尽心尽力改善C#的,比如模式匹配(一点一点加),可空引用类型,类型推导的new,Indies和Ranges,。

    但不得不说,他们的品味偶尔也会下滑。

    比如说前几天在博客园Rwing发过的的强制非空语法,给人一种画蛇添足的感觉,但考虑到历史包袱,可以理解。

    Deconstruct是我认为另外一个败笔。对于自定义类型的解构,完全没有任何必要重新定义一个Deconstruct方法,模仿Typescript(Anders大神手笔)即可。如果要解构一个经过运算的东西,就应该重新定义另一个方法返回出来。解构解构,就是将原本值拿出来,而非一个不知道怎么运算出来东西。

    var { name: x, age: y } = new { name: "xx", age: 26 }
    

    对了,还有这次模式匹配中加入了and和or运算符,最迷惑的是,if语句中不能用and和or,只能用&&和||。我只能说,闲的蛋疼,又不是Python,加来干什么。

    我吐槽完了,大家可以顶/踩我了。大家也可以去上面知乎问题发表意见,共同讨论C#语言。

  • 相关阅读:
    2019-2020-20191201《信息安全专业导论》第4周学习总结
    2019-2020-20191201《信息安全专业导论》第3周学习总结
    2019-2020-191201《信息安全专业导论》第二周学习总结
    计算机概论速读提问
    自我介绍
    20191302第六章学习笔记
    20191302反汇编测试
    20191302mystat
    20191302 第五章学习
    20191302 第四章学习笔记
  • 原文地址:https://www.cnblogs.com/xxfy1/p/terrible-records.html
Copyright © 2020-2023  润新知