 |
lua-l archive |
|
|
||
|
Brian Hook wrote:
Let me put it like this: do you use /, \, :, . or <other> to seperate path elements?
Anyway, I think the point has been made =)
Good point. I never thought about the idiosyncracies. I've actually now read the recent thread concerning this matter.
But I would like to readdress the issue; please don't construe it as trolling. I'm trying to be constructive.
I'm taking my views from the angle that Lua, to be taken seriously, must have directory listing. The first thing I did with Lua was to read a file, and then print it out to stdout. The second thing I tried to do was list files in a directory, so that I could collate information for a web page. That's where I bumped into problems. It's going to be awefully difficult for Lua to gain in popularity as a scripting language if one is almost immediately forced to extend it.
It seems that the language implementors have 4 basic options: 1. Do nothing (the one that they're doing already) 2. Use branched code, such as LuaCheia 3. Provide some kind of library linking methodology 4. Stick some code in anyway Option 1 --------IMO, 1 is a bad choice. Programmers will definitely want to list directories.
Option 2 --------I'd also suggest that 2 is also a bad option. Branching code creates maintenance headaches, and duplicates effort. Plus there is a problem of ongoing commitment. It is apparent from reading the thread that LuaCheia is already encountering this problem (no offence intended to LuaChiea developers, it's just a fact of life).
Option 3 --------This probably would be a good option. I've programmed in Tcl on two occasions (so, not very often, then). One thing I noticed it had was an ability to link in DLLs.
That strikes me as being quite a good idea. Programmers would only have to write the functionality once, away from the core of the language, and then its done. The relevant libaray is shipped with the binaries, and everyone is happy.
Option 4 --------My argument is that this isn't necessarily a bad option, despite cross-platform portability issues. Provide some incremental improvement, then hope that some day someone else will provide some other improvement, and so on, until the problem is solved.
For example, I cobbled together a directory-listing routine (like I said before, I nicked it from the internet). It uses the UNIXy way of doing things, and I am on a win32 machine. Now, providing the code compiles everywhere without barfing, at least Lua programmers have some kind of /chance/ of being able to list directories. The Borland and the VC++ guys might be disappointed, but it is conceivable that one of them will supply support for it in future.
Someone mentioned that this will tend to muddy the code, with lots of #idfef _WIN32 all over the place. In answer to their comment: yes, they're right, but I'd rather have a some preprocessing directives floating around and multiple implementations of the same code than for it to lack directory listings. In the end, it all boils down to making a design decision. And in my opinion, I think it's better to favour the inclusion of the functionality.
That leaves us with the little matter of: do you use /, \, :, . or <other> to seperate path elements? My answer would be: whatever works for my platform. I have implemented os.dir(filename) as an extension for Lua. The way that FILENAME is specified is dependent on the implementation of the mingw libraries. UNIX programmers will have to use different delimiters. Ditto for the VAX people. But does this really matter? As a Windoze programmer, I don't really care what delimiters the UNIX guys use, and vice versa. All I care is that it works for my platform. The patch that I could provide uses the opendir() and readdir() functions. My patch ought to be usable by UNIX programmers straight away, regardless of whether they use /, \ or :.
Put it this way: I know for sure that you can list directories in Python without having to resort to extending the language; on UNIX and win32 platforms. And I'm fairly confident in saying that Perl and Ruby provide that functionality, too. So, it definitely can be done!