Mats Lidell writes:
OK. So I take it that you didn't like my three function proposal!
Dislike? I would say instead that I'm a little worried. Wrapping
POSIX isn't enough for all the functionality we'd like file-attributes
(or whatever) to provide, and it might not be an appropriate API for
Windows. Also, the POSIX functions are many. I think wrapping
platform APIs as the platform provides them, plus a more abstract
`file-attributes' (or `file-info') function that gets them all, plus a
few convenience functions (eg, `file-size') is the way we should
design our API.
So your proposal is a function that returns a vector? And when we
up with a new attribute for a file we append that to the vector making
it larger. Old code will just use the front of the vector so it will
not be affected.
On the downside of this arrangement is that future attributes might
take some time to get and then all file attributes calls will
suffer. The username and groupname requires two functions calls that
you can skip if you don't need them.
Go look at the implementation. In fact there's a whole bunch of
syscalls being made. Those two function calls add only about 20%
But I guess we can have the cake and eat it. Just add functions just
on top of POSIX interface (my three function proposal) and use those
for in the more general function serving you all attributes.
Yes, that's the same idea I wrote above, I think.
If we were to change all primitives in XEmacs to something unique
and much better that would be a good argument for all elispers to
abandon XEmacs. :-)
Well, yes and no. Of course we'd need to provide a very complete
fsf-compat package. But if "much better" included not just sane API
design but also access to new functionality through that sane API (see
Steven Mitchell's posts about UI), elispers would have a strong
incentive (though past experience says not strong enough :-( ) to use
XEmacs for neat new functionality.
XEmacs-Patches mailing list