Re: Standardized Euphoria
Chris Bensler wrote:
> Here is an example of what eu/include/machine.e currently looks like in the
> prototype API:
>
> }}}
<eucode>
> -- This file is an abstraction layer to provide Empire Std library
> compatability
> -- to legacy applications created using the RDS libs
> -- These are provided in a deprecated state.
> -- When the transition from the RDS library dependencies to Empire Std library
> dependencies
> -- is satisfactory, these abstraction libraries will be eliminated from the
> standard distribution.
>
> include std/core/error.e
> include std/util/system.e
> include std/mem/mem.e
> include std/mem/binary.e
> include std/math/math.e
> include std/gfx/graphics.e
> </eucode>
{{{
>
>
> > With regards to include file handling, under 2.4 you could code eg:
> > }}}
<eucode>
> > include some\path\or\other\xxx.e
> > include xxx.e
> > </eucode>
{{{
> > and it would effectively ignore the "include xxx.e". Under 3.0.0 and
> > later it has another "look see" for xxx.e, which is fine, BUT if it
> > cannot (now) find, it CRASHES! I firmly believe it should check the
> > previous includes and if an "xxx.e" was included OK elsewhere, accept
> > that it /has/ already been included and move on...
> >
> > Or am I really the lone voice of this unacceptable incompatibility?
> > (this is, again, really all about not modifying 3rd party sources)
>
> Yer saying that if foo/xxx.e is already included and I try to include
> bar/xxx.e
> which doesn't exist, it should default to foo/xxx.e like it did when using
> previous
> versions of Eu?
>
> I don't agree. I consider the previous behaviour to be broken.
I believe that Chris is on the correct track here. I support his work and would
feel comfortable in contributing to a reorganisation of the standard library set
that comes with Euphoria. I can also see that the effort might plug a few
remaining gaps in the library functionality.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
|
Not Categorized, Please Help
|
|
