比方说，我想使用单个对象来表示一个文件，并且我想获取它的文件名（或路径），以便我可以使用该名称来删除文件或用于其他标准库过程。我希望有一个可以与所有可用的文件相关标准库过程一起使用的抽象。
我发现了FileInfo，但在我的研究中我没有找到获取文件名过程。File从软件工程的角度来看，它们FileHandle非常无用，因为它们没有提供方便的抽象，并且没有成员。
Nim 中是否有一种文件抽象（对象），它提供对FileInfo文件名的快速访问，以便一个文件不需要多个过程参数？
Nim 或任何其他语言中都没有这样的抽象，仅仅是因为您要求对大多数文件系统做不可能的事情。考虑FileInfo结构及其linkCount字段，它告诉您文件对象具有的硬链接数量。但是，除了构建和更新整个文件系统的数据库之外，无法从一个或所有这些链接获取文件名。
虽然大多数文件系统允许通过路径访问文件，但很少有文件系统提供文件的路径，因为它们实际上不需要路径！Unix 文件系统就是一个例子，其中一个进程通过路径打开一个文件，然后删除该路径而不关闭该文件。虽然保持文件打开的进程处于活动状态，但该文件实际上不会消失，因此您会遇到没有路径的文件的情况。
处理路径的问题，特别是考虑到跨平台应用程序，涉及到它自己的蠕虫：如果将路径存储为字符串，那么路径分隔符是什么以及如何转义它？您的文件系统是否支持需要特殊情况处理的卷？路径使用什么字符串编码来满足所有用户的需求？仅编码问题就需要大量的表和转换，这将使所有其他希望获得像句柄这样的文件来读取或写入字节的 API 陷入困境。
AFileInfo只是给定时间文件状态的快照，文件句柄是您可以操作的实时文件对象，路径（如果您的文件系统支持硬链接，则为多个路径）只是结束的方便名称用户。
这些都是非常不同的事情，这就是为什么它们是分开的。您的应用程序可能需要比其他程序员愿意容忍的更复杂的抽象，因此创建自己的抽象，将您需要的所有单独部分组合在一起。例如，考虑以下结构：
import os
type
AppFileInfo = object
fileInfo: FileInfo
file: File
oneOfMany: string
proc changeFileExt(appFileInfo: AppFileInfo, ext: string): string =
changeFileExt(appFileInfo.oneOfMany, ext)
proc readAll(appFileInfo: AppFileInfo): string =
readAll(appFileInfo.file)
这些过程只是模仿各自的标准库 API，但使用更复杂的结构作为输入并根据需要进行转换。如果您担心由于额外的过程调用而导致此抽象未得到优化，您可以改用模板。
然而，如果您遵循这条路线，在某些时候您将不得不问自己对象的生命周期AppFileInfo是多少：您是否使用路径创建它？您是从文件句柄创建它吗？访问file部分代码中的字段是否安全，或者是否未正确初始化？当出现问题时，你会返回错误或抛出异常吗？也许当您开始问自己这些问题时，您会意识到它们是特定于应用程序的，并且很难针对每个用例进行概括。因此，这样一个复杂的对象在语言标准库中没有多大意义。