Re: Standardized Euphoria
Chris Bensler wrote:
>
> I'm working on designing new standard libraries for Euphoria to replace the
> RDS libs that are shipped with the distro.
>
> I have a few questions.
>
> 1. Besides additional functionality, I would prefer to redesign/reorganize the
> existing libs. Would this be acceptable to people?
Ok, it sounds as though most people are in agreement on this topic, so it will
proceed.
On to the next issue:
> 2. Many things that would be added to the standardized libraries would collide
> with existing projects that define the same things in it's own code.
> This problem is unavoidable if I wish to expand on the RDS libraries, but I'm
> sure it would deter many people from migrating. Any opinions on this?
The collisions I'm referring to here are the addition of things like
TRUE, FALSE, NULL, abs(), or_all(), etc...
Although we already deal with these types of collisions anyways.
I've included a prototype distro which only contains the RDS libs reorganized,
along with the abstraction files.
Have a look and let me know if you have any suggestions.
(Euphoria Library Foundation)
http://www.empire.iwireweb.com/dl/elf-api%20v0.0.1.zip
There is a few things to keep in mind"
1. There is currently no additional functionality in the elf api other than a
couple of things.
i) std/core/declares.e defines some addtional constants (TRUE/FALSE, etc..)
These additions demonstrate the conflict I mention in my #2 query. If you try to
run the distributed eu demos, you will find that you need to either modify the
demos or modify the elf libs.
ii) safe.e was changed to std/mem/debug.e and uses a slightly different
technique which allows debug.e to be used in conjunction with std/mem/mem.e by
simply including it before including mem.e, instead of the previous behaviour
where safe.e was a replacement for machine.e
This change is not definite since the method involves the use of routine id
which could affect code cleanup when binding (or translating?). (look at the
DEBUG ROUTINE PLACEHOLDERS in std/mem/mem.e)
I'll explain the issue in more detail at a later time when someone brings it up,
although I think it's probably insignificant.
2. the subfolder structure is not definite, it's only a prototype for now to
provide a basis and to get the idea across. Some of the subfolders seem sort of
redundant, but there will be many more files added.
Perhaps before we figure out what the structure will be like, we should decide
on what kinds of things will be added?
3. the xtra/ subfolder does not belong. The elf api should contain only primary
functionality.
I think msgbox.e should be deprecated in favour of a win32 API and database.e
deserves to be it's own distribution.
4. ideally, extraneous functionality such as a win32 API and various database
systems will be supported officially by at least affirmation of conformity and
quality.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
|
Not Categorized, Please Help
|
|
