CraftOS-Standards
CraftOS-Standards copied to clipboard
Lua API format
As discussed in #26 and #18, the Lua format is being split in to separate types.
This format is exclusively for files that are loadable via os.loadAPI
. It might be worth also considering what to do with files that are APIs but use some custom API loader or class system. Maybe a miscellaneous Lua format?
Also see: #39 and #41.
I would rather move this standard to CraftOS-Standards/File Formats/Source Code/Lua/
.
@viluon Okay, good idea.
What obstacles remain before we can accept this proposal?
The proposal defines .api
as the API file extension, but states that an API is anything that loads without issues with os.loadAPI
. That means that APIs following this standard would have to be accessed like so:
_G[ "myAPI.api" ].foo( "bar" )
I don't think that's intended. Any sane being (no offence @lyqyd, I saw LyqydOS source) would avoid os.loadAPI
at all costs. Besides, a standard Lua source loads with os.loadAPI
just fine, it actually doesn't have to specify any global variables, and would therefore not be considered an application programming interface at all.
Hmmm that's a good point @viluon. I really wish @dan200 would add support for extensions for os.loadAPI
(although for some reason I feel like he has...).
Perhaps .api
is the recommended extensions, but no extension is supported.
I'm not entirely certain why we're pushing in the direction of everything having a file extension. It makes a lot of sense with pure data files, like nfp, or even table. It doesn't make a lot of sense (within the context of ComputerCraft) for executable files, like lua programs or APIs. It's definitely true that there are blurry lines between programs and APIs especially, given the way they are loaded and run. Can we get away with no file extension on both apis and programs?
@lyqyd the main issue is detecting the MIME. Extensions make it easy. So, if they are going to have different extensions, then ideally, yes, they would have different extensions.
That said, I think in realise people are going to want to have no extension for both, so we'll need to figure out how that should work.