TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Representing Heterogeneous Data

59 点作者 grep_it超过 1 年前

3 条评论

elcritch超过 1 年前
&gt; This is a real trade-off. The feature I have here provides strictly less static safety than using sum types. There is a slight performance cost to checking the type tag when accessing case-specific fields. In return, you get simpler, more familiar syntax for working with case-specific fields, including mutable ones.<p>Interesting post! Nim uses variant&#x2F;case objects as well. Generally they&#x27;re pretty handy and more flexible than sum types as you can access non-variant fields as regular objects. Though it means you can&#x27;t use the same field name twice, however on the other hand you can bring common fields out of the case portion. Also, a single object can have multiple case variants which can be handy.<p>There&#x27;s a PR for adding the stricter sum types and pattern matching as well. <a href="https:&#x2F;&#x2F;github.com&#x2F;nim-lang&#x2F;RFCs&#x2F;issues&#x2F;525">https:&#x2F;&#x2F;github.com&#x2F;nim-lang&#x2F;RFCs&#x2F;issues&#x2F;525</a> Currently I just use a library for sum type syntax on top of object variants: <a href="https:&#x2F;&#x2F;github.com&#x2F;andreaferretti&#x2F;patty">https:&#x2F;&#x2F;github.com&#x2F;andreaferretti&#x2F;patty</a>
gavinray超过 1 年前
For what it&#x27;s worth, the representation the author chose to go with is almost verbatim identical to how you declare variant object types in Nim.
skybrian超过 1 年前
A bit surprising that this shows up here even though Bob apparently hasn’t figured out a good answer yet. Maybe someone will know a good solution?
评论 #37725299 未加载
评论 #37725397 未加载