Re: Standardized Euphoria
Chris Bensler wrote:
>
> 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)
> <a
> href="http://www.empire.iwireweb.com/dl/elf-api%20v0.0.1.zip">http://www.empire.iwireweb.com/dl/elf-api%20v0.0.1.zip</a>
>
> 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 ~
> <a href="http://empire.iwireweb.com">http://empire.iwireweb.com</a> - Empire
> for Euphoria
Hi
I've had a look at that folder/file structure - would I be correct in thinking
that the
way you want to take it forward is to have th 'old' standard includes in the top
level,
and the 'new' standard includes within a new folder structure under
/include/std
If so - I like it - it should retain backwards compatability that way.
Bear in mind that any file reorganising should not be exclusive to windows,
and that win32 api functions are not necessarily part of a standard euphoria
installation (ditto the wxwidgets and other cross platform GUI's)
This IMHO, should be a good thing.
Chris
PS please don't start any function names with CB!
Chris Burch
|
Not Categorized, Please Help
|
|
