产品设计私单网站wordpress the post
2025年9月11日
从这篇日志开始，是用 Markdown 文件写在文件的 journey 文件夹中，每篇日志对应一个文件。写完之后再同步到 CSDN 。毕竟在国内访问 GitHub 和写地理选择题没有区别。
之前的日志就不誊抄了。Rail参考文档和Rail语法参考会写进 journey 文件夹。目前的 Rail 的两篇参考文档写得很苟矢，嗯，以后有空再改吧。
原文没图。发在 CSDN 的版本有图，方便阅读。
现在是大一的开学第二天。室友写作业我写作业，室友打游戏我敲代码。
关于重构信息类（Reference）的决定
之前的四个基本类型是，信息（Reference)，分布(Aggregate)，细节(Rail)，构成(Category)。还有个要素，也挺基本的，但不算基本类型，因为写网址目录的时候可能不知道链接是什么。
在用 Rust 实现这些类型的多态的时候，注意到一个很像量子力学的结构：
| 之后 | 实现为信息 | 实现为细节 | 实现为分布 | 实现为构成 |
|---|---|---|---|---|
| 来自信息 | # ref | name # ref | - node # ref | + cat # ref |
| 来自细节 | # ref = value | name = value | - node = value | + cat = value |
| 来自分布 | X | X | X | + cat - node |
| 来自构成 | X | X | X | X |
信息之前的作用是一个模板的用法，这也是我觉得 Rail 语言有用的一个理由。后来在做前端，感觉省几个字不仅用处不大，还增大记住模板的语境负担。所以就想着把从细节到信息的映射给删掉。
那就是标签。所以信息这个词的译名就从 Reference 改成了 Tag 。其实一开始改成了 Trait ，但是觉得撞了 Rust 的关键词可能会让代码产生某些意想不到的行为。。。。。。
基于某些连我自己都描述不好的心里动机，顺便强调了 Element 的存在。一番爆改之后是这样子：
| 之后 | 实现为要素 | 实现为信息 | 实现为细节 | 实现为分布 | 实现为构成 |
|---|---|---|---|---|---|
| 来自要素 | O | # tag | name = value | - node | + cat |
| 来自信息 | X | O | name # tag | - node # tag | + cat # tag |
| 来自细节 | X | X | O | - node = value | + cat = value |
| 来自分布 | X | X | X | O | + cat - node |
| 来自构成 | X | X | X | X | O |
嗯。就这样子。
然后代码是这么组织的。因为文件太多了，所以以后可能不会每次都把所有的代码都贴上来，除非这个版本很稳定。
显然，这个目录结构是用 Rail 语言写的。（Micro 成就感
line.rs
opera.rs+ line+ elementmod.rsfrom_meta.rs+ tagmod.rsfrom_meta.rs+ railmod.rsfrom_meta.rsfrom_tag.rs+ aggregatemod.rsfrom_meta.rsfrom_rail.rsfrom_tag.rs+ categorymod.rsfrom_meta.rsfrom_tag.rsfrom_rail.rsfrom_aggregate.rs+ omissionmod.rsplaceholder.rs+ commentmod.rsfrom_meta.rs+ importmod.rsfrom_meta.rs+ nilmod.rsfrom_meta.rs+ operameta.rstag.rsrail.rsaggregate.rscategory.rs之后的开发规划
在最开始的时候，Rail 的设计只是放置网盘提供的下载链接，而且是用 JS 写到 .html 文件的 <script> 标签里的。后来才觉得也很适合写小说，适合收录绘画教程，适合收录各学院，专业，班级的群，适合表达一般的文件结构，。。。
所以，目前的想法是，先用 Rust 做一个表示基本类型的 crate，然后再慢慢写实现。比如说最开始的用途的实现叫做 wsc， 是 Wed Sites Collection 的缩写。