HE Shi-Jun
HE Shi-Jun
由上述历史记录，文中所写的实现只是2014年之前的实现。当然我们也可以认为后来越改越糟了……
似乎两个版本在非10进制数上的结果其实是一样的……所以到底动机是什么我还是不太清楚。 另外似乎所有实现都有个bug一直没发现，就是虽然可以支持 `0x100`，但是不支持 `-0x100`（当然 `+'0x100'` 可以返回 256，而`+'-0x100'`返回NaN 本身就是个坑）
文中有一个问题： > 实际上这个比上面那个正则的版本更好，因为这个还同时处理了非字符串的case ~~这一点是不成立的~~，因为 ```js function isNumeric(str) { return !/^\s*$/.test(str) && isFinite(str); } ``` 这个版本其实也处理了非字符串的case。【脑子不清楚，虽然处理了，但是处理结果不是我们预期的😂】 所以我认为这个版本~~其实更好~~，代码意图很清晰。而用 isNaN 和 parseFloat 需要程序员理解额外两个函数的行为（尤其是parseFloat的行为），心智负担更大。 唯一的问题是非10进制数的坑。（就是额外允许了 `0x100`但是不允许`-0x100`，虽然感觉这个是edge case，直接忽略也不是不可以。） 所以可以改成这样： ```js function isNumeric(n) { return /^[0-9.eE+-]+$/.test(n)...
@CJex 文章对于 `isNumeric` 的含义确实在一开始写得不够明确，不过如果仔细读，可以看到这句： > 如果参考input[type=number]的规则 所以实际上文章中 `isNumeric` 的需求是『实现与 input[type=number] 规则一致的逻辑』。为什么是这样的需求呢？看下面： > 你所说的「用户还是可以通过修改页面上的元素绕过这些检查」这种情况，前端不需要考虑 这里的「用户还是可以通过修改页面上的元素绕过这些检查」其实是暗含后端进行检查的需求。而联系上文可推导出，『实现与 input[type=number] 规则一致的逻辑』『用于后端检查』。 为什么后端检查要用与前端一致的规则？ 诚然，我们的确可以用并不完全一致的规则，即前端并不接受的（比如包含头尾空白），后端也可以接受，前端接受的（比如科学计数法），后端也可以不接受。但这比较容易导致用户体验的不一致。 另外一种可能的 use case 也是从用户输入中提取数字，但是不能直接用 input type=number 的情况，比如需要允许用户输入非数字的其他值。 > 后端正确的做法应该是如果请求的JSON Payload反序列化后得到的不是（合法范围的）Number应该直接抛出400错误 当你提到 json...
> 我第一个正则版本判断非字符串不行的 @akira-cn 发现半夜写文章的时候脑子锈住了……
感觉上生成扑克牌其实用generator还是大材小用了。 可能这样就够了： ```js const cards = [] for (const suit of ['♠️','♣️','♥️','♦️']) for (const point of '123456789TJQK') cards.push([suit, point]) ``` 或者 ```js const cards = ['♠️','♣️','♥️','♦️'].flatMap(suit => [...'123456789TJQK'].map(point => [suit,...
@yujiangshui 最初不喜欢grunt最主要原因是写出来的配置代码又臭又长，还不如直接写命令行脚本或者Makefile。深层问题则是它仅仅是一个task runner，对build应该怎么做本身没有约束。 gulpjs有几个很好的地方。 第一是有一个基于流和管道的模型，符合unix工具组合的传统。基于这样的模型，使其能形成互相协作和有序竞争的插件生态。 第二是代码的写法比基于配置的grunt要简洁和一致。 第三有性能优势。当然这一点broccoli有不同意见。 这些优势非常明显，以至于在grunt已经那么火的情况下，gulp出来没多少时候就可以跟grunt分庭抗礼，并且绝大部分功能都有对应插件——这一点broccoli就比不上（刚出来时蛮火的，但发展势头似乎现在有些停滞）。 @simongfxu 插件杂乱无章这个事情我不是特别同意，整个nodejs的生态就是这样的，同样的事情可能会有很多modules。 第一，有竞争是好事。 第二，相对来说gulp由于模型的限制和其社区的严苛到变态的要求（看看有多少插件被以不符合gulp的理念而被干掉），所以每个插件的功能都相对单一，其竞争是相对有序的（只拼单一功能），所以会很快收敛到一个最多几个共存。有几个共存的原因往往是因为其底层实现确实不同，这是很正常的。 第三，gulp确实存在一些问题（比如错误处理），我们使用中也遇到，不过这些问题应该在下一个大版本4.0会解决，尽管4.0迟迟不出来也是个问题，但是就目前而言我还是愿意再耐心等待下。 如果需要的是开箱即用，那么grunt也许还是一个ok的选择，但是对于我来说，开箱即用不是我的主要目标，所以会选择架构上看更好的gulp。
>since it already has existing semantics. @ljharb I think overloading `+` for tuple/record is possible, just like how we overload `+` for bigints. So `#[1, 2] + #[3, 4] ===...
@benjamn @jdalton
> There was a significant amount of effort put into TLA to ensure it would not be breaking for a module's dependencies to use it. @devsnek How? As my last...