类名首字母小写在有些语言里是习惯写法。变量名全大写倒是没见过。

函数式编程。

但凡看一眼 v2 上面的腰子团队挂的招聘还有讨论虚拟币的都是些什么人，都觉得学校在这事情上挺良心的

本质的区别就是一个是 POST ，一个是 PUT ，这是 RESTful 定义的，和 Spring 注解没啥关系。

再不然看源码也好。「既可以……又可以……」更多是编程语言具体实现的问题，可以这么做不代表它是合理的。

唉，资本

话费账单就足够了吧，至少国外是这样。

怎么会有人觉得好的，正确的做法难道不是普通 app 之间互通，涉及敏感信息需要二次验证、重新登入吗。

大部分主流网站都是这么设计的，百度的这种纯逆天设计都有人洗地。说 Google 和微软都这么设计的怕不是只用过 Google 搜索和 Bing 搜索。

当这个问题被提出的时候，答案已经不言自明。

听上去很像 Notion （

@Greendays 还有电池

崩坏星铁可以用 parallel 玩，效果还挺好的，就是触摸板操作极度诡异

mac 的 Edge 没有 bing 之类的乱七八糟的东西吗。之前在 Windows 下就受不了三天两头更新一堆乱七八糟的功能。

Arc 感觉还是省心，特别是在一些 Safari 渲染不正确的页面上，又不想折腾半天配置 Chrome 。

@DOLLOR 有时候显式类型标注可以起到文档和契约的作用，当然一般来说不是 string 这种简单类型而是复杂的 model 或者联合类型。

静态类型的意义是这种写法是完全可选的，哪怕没有注解，也可以根据上下文尽可能推断出变量的类型（ File[]算是少数反例了，但至少静态类型能推出个 any[]来）。

动态类型里面完全没有这种契约关系，所以真的要把类型约束推出来的时候，还得四处添加 userland 的 type hint ，而这就是 Turbo 的用户将要面对的情况（或者完全不考虑这些写面条代码）

@cmdOptionKana 说实话我并不讨厌 Ruby ，甚至以前还有一些兴趣（可能因为是比较早就流行函数式写法的原因），只是说现在会觉得没太多兴趣了。

@beginor 看了一下 three.js ，说法并不是移除 ts ，而是把 ts 支持转交给专门的团队来做，这和一个 force push 直接覆盖掉整个主线有本质上区别吧。

@Mark24 类型是和数据建模直接相关的，这难道不是逻辑的一部分吗？静态型才能够提供类型推断，TypeScript 之所以有时候还需要写类型标注恰恰是因为 JavaScript 太灵活。

@kongkongye 所以更不懂关于 TypeScript 的争论了，再不济写 any 也好过吧

@oops36 对于 lib 来说删掉 TS 算是一种选择，但是按理来说删掉 lib 应该引入单元测试和文档来覆盖掉类型本应起到的作用，然后一堆人在那里抨击 TS 却对文档和测试闭口不谈……

@DOLLOR +1

用`()`和`$x`（这里的 x 是数字，从 1 开始）来替换。

假设你这里每一个标题都是单独一行的话，那么每一行只捕获一次匹配，那么需要的就是先提取出每一个标题：

`(^第.*章.*$)` - 这里`^`假设标题紧跟着每行开头开始，如果不是的话就要去掉，如果每个标题有更多特征，比如有固定字数，可以进一步限定进去

然后在替换栏里面输入要替换后的模式，括号里面括住的部分用`$1`来指代，那么就是：

`[h1]$1[\\h2]` - h2 前面的反斜杠要转义一下（有的语言里可能会不一样）。

如果 op 有用 IDEA 的话，可以试试用 IDEA ，里面会对正则表达式替换有预览的。

可能缺的是能陪 op 一起用 1065 玩游戏的妹子。

话说双人成行的配置要求这么高的吗。

Spring Boot 和 Java EE 是企业级架构，那可以用来写 Minecraft 吗。

@huzhikuizainali 如果是 Java 语境里的「继承」关系，一个接口不能被具体实例化，接口和具体类之间的关系当然不是继承关系而是典型的子类型关系。codehz 的回复应该很清楚了。所以您应该知道前面问题怎么用代码来写了。

而您的直觉也是正确的。

我重新想了一下，或许这里讨论的是那种典型的 class extends 关系的，也就是父类先调用构造器后子类再调用构造器，然后逐个字段填入属性的这套过程。如果只从 Java 的角度很狭义地考虑的话，那么这个过程里面确实和对象有一点关系——调用构造器后会创建一个对象。或许，他想介绍一个子类对象可以被强转为父类的对象。这是我能想到的所有东西了。

但是这个提法显然是有问题而且很含糊不清的。子类型或者继承/派生关系也确实不需要牵扯进来具体的对象的概念。说实话，关于类继承和接口继承，我觉得那两句话里面的对象换成类型，也就「类继承根据一个类型的实现定义了另一个类型的实现」，「接口继承描述了一个类型什么时候能被用来替代另一个类型」，反而更准确一些。不知道是书本翻译的问题还是原书对一些概念的解释不清楚。

Java 的 OOP 和 C#的 OOP 没有本质上的区别，可能和 C++的有点区别就是。