不喜欢，但如果我自己选我不会选 Java 。非要用的话可能会考虑 Javalin 、vertx 或者 Ktor 吧。

所以不要把 master 合入分支，分支上面只用 rebase 。

另外关于返回值，我给出的`ISomeVisitor`本身是用 T 去参数化限定它的返回类型。但是在业务代码里面返回类型受限应该不是什么问题？考虑一个复杂数据类型树的话，那么用泛型和返回值可以让 visitor 的职责更清晰吧？

比如说一个订单和用户还有交易构成的数据类型的话，定义三个 visitor ，比如说

```java
class OrderVisitor extends ISomeVisitor<IOrder>
class TxVisitor extends ISomeVisitor<ITx>
class UserVisitor extends ISomeVisitor<IUser>
```

然后自然而然每个 visitor 的 visit 和 accept 分支都会遵守「这个 visitor 只处理和基类相关的职责」，最后再把 visitor 互相组合起来，不会比一个巨型的，什么都可以做的 visitor 更加清晰可维护吗？

A little Java, A few Patterns 里面也有提到 visitor 之间可以组合嵌套的例子。

我在实际代码里面就遇到过那种「一个巨型 visitor 同时承担很多职责」的例子，比如一个 ColorScheme 相关的 visitor 里面不光处理颜色，还要处理字体、排版，甚至把 cache 相关的函数都塞进去的情况。我不觉得哪怕在业务工程的考虑上这样的代码也比使用返回值和泛型参数的代码更好维护。

@mahaoqu 话说 Expression Problem 有什么具体的文章或者讨论可以指一下路吗？我想看看。

@lesismal 我倒是对设计模式并没有怎么太去学，但是造自己语言思考语义和语法的时候，再结合平时的日常工作，就不免会回过头想这些问题。

@zhuisui 换句话说就是 visitor 从设计模式的角度讲只追求分离，并不在乎 dynamic dispatch 和子类型的运行时自动求解，对吗？如果从这个角度讲，那么似乎说得过去……但这么一来这个设计模式对我的兴趣可能也就剩不下多少了。

@GiantHard 我觉得你说的有道理。感谢。

电报我就觉得更不用提了，随意撤回这个功能甚至都让电报成为了电诈活动的温床了。你要说小圈子群聊有氛围，那你找到了正确的群，Q 群也可以「讨论氛围很学术很严谨」。

reddit 是怎么个讨论法，版主买个 automod 把贴子秒删还是一 moderate 就 moderate 到天长地久，还是看版面管不住急眼了就跑出来给每个活跃用户都发个 permban ？

karma 这个也属于经典「本意是好的，但执行坏了」。在 hackernews 和 stackoverflow 搞得好好的，跑 reddit 就成了 mod 随意乱删帖+karma farm 大灌水的双板斧。

我可不觉得这有多严肃。

@sagaxu 没必要抠字眼，我人在国外平时用的都是 visitor ，没那么熟悉中文定义。再说我这篇贴子里有提到一个 observer ？

@w568w
@nightwitch


我能想到的一个「针对依赖访问状态」的解决办法就是加一个中间层来表达顺序访问或者访问次数等信息，最简单的实现可以是这样的：

```java
interface IResult<T> { ... }
class Skip<T> implements IResult<T> { ... }
class Ok<T> implements IResult<T> { ... }
```

这只是个例子，不代表说一定要这么做。当然实际业务代码几乎没人这么做就是，但我想说的是这个「依赖访问状态」并不是无解的。

而且换过来说，业务代码里增加不同的层级和抽象不也是很经常的手法嘛？ Stream 或者第三方库里面这样的工具也很多，为什么在 visitor 模式上反而不能够通过增加一层来解决问题了呢？引入可变状态和副作用的代价就不需要考虑一下吗？

而且很多场景，例如我自己参与维护的一些代码项目里，经常在重构的时候需要花大量时间理解修改状态和副作用到底怎么桥接起来，最后发现很多代码实际上压根不依赖于访问状态，也对访问顺序没有任何前提要求，看起来更像是单纯的惯性所致，而且这样的 visitor 见一两个也就算了，项目里到处都是而且平均 LOC 几百上千行的时候，连重构都难下手。这也是我提出这个帖子的问题的原因——以前我是默认「 visitor 模式需要有状态，只是我不懂，可能工程代码里有最佳实践」，但在工作一两年接触了更多工程代码后，现在我对这个定论更多持有怀疑态度。

反过来说，以教育和入门为目的的代码样例，例如大学 OOP 课上的代码，也是出于「 visitor 需要依赖可变状态」的前提来设计代码实现的吗？

这里的问题在于，副作用、修改全局变量这些本质上都是不可推理并且无法用类型等东西来建模的，固然可以用单元测试来「告诉使用者这个 API 怎么使用」，但作为一个同时维护和使用 API 的开发者，我对这样的代码有极大的不适感。

@donaldturinglee 我了解这个网站，而且这个网站也属于我提到的「用副作用实现观察者模式」的例子。

对于 boolean 的属性，也就是类型是`bool`的变量、字段或属性，isXxx 没什么不好的，而且还能统一清晰的让人知道这个字段表达「 XXX 的状态」这个概念。

真正有病的是某些语言里 boolean 的 getter 非要叫 isXxx ，所以禁止 boolean 属性以 is 开头这件事。

你把它理解为 Self 类型的模拟就行了。感觉 Java 就喜欢制造一些很奇怪的术语，例如把好好的协变逆变叫成 PECS 。

之前写过一点 Swift 的感觉是如果只是满足于堆砌 UI 或者简单的应用那 Swift 还是蛮足够的。但如果要稍微往深了做的话，似乎 Swift 不太够，得上 OC 。

不过那之后我就溜了（

也许可以先试着把 Swift 弄熟悉吧。

@songray 虽然 var 那个确实有这个想法，但是其实某种程度上我还蛮喜欢 JS 的（ bushi

@mekingname 这个思路不错，感觉可以再考虑一个专门应对它的设计模式（

@koykoi 这个之前也有看过，甚至有做过一点贡献（ bushi 不过感觉 Dreamberd 比较偏向前端，和我的想法不太一样

@FalconD 认同

@kneo 听起来有点规则怪谈了

@DOLLOR 想起 PHP 那个 semicolon 了……

@FYFX 这个不错！不过感觉实际实现有点难度，很可能在实现之前自己人先晕了

@jianchang512 说到 try/catch ，我倒是想过一个只有 try/catch 来表达控制流，并且所有 if/while/for 都得用 try/catch 模拟的语法……

@soul11201 感觉这个思路是「做一件事，但做得马马虎虎」，刚好和 unix 哲学背道而驰

@spongebobsun 随着 JS 不停刷版本，其实 JS 似乎反而还越来越像个正常语言了……而且 JS 有许多灵活的东西我还是蛮喜欢的（叠个甲，我是静态强类型阵营的）

@llsquaer 不完全是，某种程度上我觉得 JS 的设计虽然有很多问题，但是其实已经算是蛮健全（？）的了。在低代码或者企业级技术栈里面有更多古神低语，当然 JS 的一些上古框架的很多设计也确实很难绷。

@xuld 其实我倒是有想做自己的语言，但是就像你说的，成熟的语言需要一整套生态和工具链，我眼下优先可能考虑更健全的设计吧，不过这个倒是后话了……问这个问题某种程度上算是吐槽（）

@jspatrick 可能因为我比较熟悉 JS （

@ayase252 这个似乎确实某种程度上算是个潘多拉魔盒了……感觉也确实是这个问题下的必选项（）

@ns09005264 还可以再加个 0 、void 和空字符串

@DiaoWang 想到了一个叫 BANCStar 的语言了（虽然跟你描述的不太一样，但感觉思路很像）

@8620 可以指一下路看看是什么课程嘛，感觉很有趣想 follow 一下，顺便也从比较高层的语言设计转向底层实现，近半年主要是自学 UW PL 和 Scala 的公开课，然后自己断断续续看书写自己语言搞各种东西，不过都离底层或者硬件实现感觉有点太远了（

@Binwalker +1 ，话说我给对象转码开小灶就是从 lambda 和递归上手的，感觉效果还不错，很多东西一开始讲通了后面再深入就方便很多了。

Excel ，ActualBudget ，或者自己写

没有办法做到，某种程度上说这是 Java 的一大缺陷了。

放心，以后也不会修，因为这个功能养活了许多设计模式。

一大波软粉在前来的路上。

（以及企业版也不好使，我都快给 Windows 自动更新搞破防了，然而软粉只会跟你不停复读说你不会用 Windows ）

主要也是我的使用场景里面重度依赖 WSL ，好几次更新完发现 WSL 和 IDEA 等工具出现各种离谱问题。。

感觉先把 Core Java 学好最重要吧。