1. Standard library direction
- Posted by ChrisB (moderator) Sep 23, 2008
- 921 views
Hi
A recent thread by Don Cole lead to the suggestion that a win32 (disk stats) only function was added to the standard library.
Might I respectfully suggest that a function that is platform specific is not added to the standard library, as then the library will no longer be standard.
There could be an option to add win32 functions to a sub directory include/std/w32 (and by inference an include/std/lnx subdirectory).
I believe I remember seeing, back at the inception of the standard library project, that one of the constraints was that all functions and procedures contained therein should be cross platform.
Chris
2. Re: Standard library direction
- Posted by DerekParnell (admin) Sep 23, 2008
- 903 views
A recent thread by Don Cole lead to the suggestion that a win32 (disk stats) only function was added to the standard library.
Might I respectfully suggest that a function that is platform specific is not added to the standard library, as then the library will no longer be standard.
Firstly, those functions have not been added to the library. Only permission was sought.
The term 'standard library' means the library that is officially supported - nothing more. If such a library contains platform specific functionality it is still a standard library.
In fact, the standard library already contains platform specific functions. Consider the DOS only graphics routines, and the get_curdir function, used to get the current directory for specific Windows/DOS drives. There is also the driveid() function that returns the drive ID from a supplied path. And not to forget, message_box() which is a Windows only routine.
And realize that if the Windows version of the disk stats functions were added, it does not mean that a Unix version can never be added, because all it needs is someone to write it. There is no requirement that the same person writes ALL the variations of a function for different platforms.
There could be an option to add win32 functions to a sub directory include/std/w32 (and by inference an include/std/lnx subdirectory).
This maybe useful for stuff that can only be platform specific. We already have a std/dos directory. Maybe the message_box() function should be moved to std/win?
I believe I remember seeing, back at the inception of the standard library project, that one of the constraints was that all functions and procedures contained therein should be cross platform.
This is plainly not possible nor is it actually a real requirement. It would be a good thing that, wherever possible, cross platform versions of routines existed, but there will always be some routines that can only be platform specific - and still be officially supported.
3. Re: Standard library direction
- Posted by jeremy (admin) Sep 23, 2008
- 930 views
This is plainly not possible nor is it actually a real requirement. It would be a good thing that, wherever possible, cross platform versions of routines existed, but there will always be some routines that can only be platform specific - and still be officially supported.
I think that if a function has the ability to be cross platform, that it should not be added to the library unless it is cross platform. If we wait for someone to submit a function to do that on Unix then we will have an incomplete standard library. What will happen is John Doe will develop a program on Windows and then go to run it on Linux and find out that hey, function abc() only works on Windows. But why? It simply gets an environment variable, you can do that on Unix too! (bad example, but an example).
I do not have a problem with a function that is only available on one platform to be added and marked as a Windows Only function. For instance, getRegistryKey() or something to that effect. Now, in that example, it would be nice for a cross platform configuration library like the java.util.Preference class or something, but that's another story.
I do think that the integrity of the standard library should be kept up. I believe it's far worse to introduce a function on Windows that has a Linux counter part, but leave the Linux counter part out waiting for someone to develop it than to simply leave both of them out. A standard library only supporting 1 platform is going to leave a huge distaste for people when looking at Euphoria. It really would be better if the function did not exist than to exist for only one platform.
Jeremy
4. Re: Standard library direction
- Posted by ChrisB (moderator) Sep 23, 2008
- 974 views
Hi
Thanks Derek, for the clear and concise explanation of the current thinking behind the standard library. One of the reasons for not signing up to the Devs list (as well as my below standard (sic) programming skills, were that I did not wish to become involved in the minutiae of definition. If this is how the Devs are taking the standard library forward, then I fully support that, for all the stirling work that they are putting into the project, and in driving Eu 4 forward.
Some google and Wikipaedia research has shown up the mess that is the current standard library situation in the C and C world - to the extent that different compilers will not compile each others standard library. CLearly there have been some compromises, optimisations, and I suspect some egotistic manipualation.
However, this need not be the situation with euphoria (until other interpreters / translators become available that is)
As Jeremy said, to have a function available on one platform, and then not available on another (remember this is the beauty of Euphoria), would be most frustrating. There are obviously going to be functions that cannot be wrapped from one platform to another, and there position within the library tree should show this (as in the std/dos directory).
In order to prevent standard library stagnation, if a function is developed for one platform only, it should go into that library's directory, until such time as it becomes cross platform, and it can then migrate out into the general trunk. I suspect that what will happen is that a platform specific function will be written, will reside in its platform directory, then someone else will come along who needs the function on another platform, and will write it for that platform. I am sure that liberal use of the ifdef keyword will be made.
Finally I respect fully all the Devs hierarchy and vetting procedures for introduction of new functions to the standard library - http://openeuphoria.org/wiki/euwiki.cgi?EuphoriaDevelopment - but I do feel that allowing single platform functions 'willy nilly' (as great and useful as they may be) into the general trunk, would be a long term mistake.
Chris
