-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
attribute mode #31
Comments
Agree that the name is unfortunate, but the lfs API has been there for a long time, it would break lots of stuff if it was changed. What's being proposed here exactly? |
You could add a new (preferred) name, and mark the existing one as deprecated. |
I agree the name is a bit odd and I wouldn't have chosen it myself, but IMO I don't think the change is worth the hassle: people would write code with the new name, and then users with existing installs of lfs are forced to upgrade just because of that one string, but not after some breakage and headscratching (especially in a dynamically typed language, where things fail at runtime, often silently). |
Thats why you transition it over a number of versions... the alternative is not to change anything (the other thing thats ugly is the iterator spec for directory traversal which looks like it was developed for an earlier version of Lua and adapted). The problem is that these older projects (luasocket, luaposix and this one) are copied as APIs by newer stuff too (eg openresty copies the luasocket interface) as models for how Lua interfaces should be. So we should be trying to improve them, and defining a specification. One model would be that they could change in sync with core language changes, so there could be a release for 5.3 with changes, as people will need to update their code then anyway, as the language does not have full compatibility. |
We should rename 'mode' in lfs 2.0 and leave the old name supported but deprecated. What's the preferred new name, 'filetype' or just 'type'? |
i don't know, but for me, on archlinux, and installed by luarocks, attributes functions doesn't return nothing (mode or not). empty table for file or for directory entry. |
Calling the file type "mode" is a bit odd, as "mode" usually refers to the actual read/write protection. I am working on an luafilesystem compatibility layer for ljsyscall and already have a mode field, so I have called it "filetype" and have a compatibilty fix to return as mode in the lfs layer, as "filetype" seems a bit closer to what this field returns...
The text was updated successfully, but these errors were encountered: