OpenEuphoria

Re: Packages

• Posted by Matt Lewis <matthewwalkerlewis at gmail.??m> Aug 09, 2007
• 506 views

Derek Parnell wrote:
> 
> Maybe I just don't understand the problem or situation.
> 
> I thought that the idea was to have certain identifiers accessible from some
> files but not other files. To me, this seems to imply that we need to be able
> to indicate which identifiers can be shared this way and which files will do
> the sharing.

Yes, I agree.

> Now if you don't like the file system of grouping files into a package, we
> could
> devise a file-system agnostic method. For example, creating a special file
> that
> lists the files in a package. For example we could have a file called
> win32lib.e
> that contains ...
> 
>  package win32lib
>     include win32/memory.e
>     include win32/core.e
>     include foo/bar.e
>  end package
> 
> Which would mean that statements inside these three files could access the
> 'package'
> designated identifiers in those files and no other file could.
> 
> Then to use this package in an application we just use the standard mechanism
> ...
> 
>   -- myap.exw
>   include win32lib.e

Ok, so we (that is, the parser, etc) would just have to know not to allow
myap.exw to see any of the symbols declared as 'package' within any of those
files, unless it was included elsewhere outside of a package definition.

So [thinking out loud here] let's assume that machine.e had some stuff
declared as package, and it's included somewhere within win32lib.  myap.exw
could
still see the machine.e packaged symbols if it explicitly included 
machine.e somewhere.

Should we use a different syntax for either declaring symbols or the 
package...end package to differentiate which one we're doing?) Maybe
with/without package:

-- win32lib.e
 with package
    include win32/memory.e
    include win32/core.e
    include foo/bar.e
 without package

 -- myap.ex
 include win32lib.e

Do we even need to name a package?  How would the name be used?

And presumably, all symbols declared (in an include or in the file itself)
would be part of the package, and subject to the new visibility rules:

-- app.ex
with package

package atom myAtom
include someFile.e  -- can use myAtom

without package

include otherFile.e -- can't use myAtom

What about 'nested' packages?  For example, somewhere within the bowels 
of win32lib, there's a file or other library that declares its own package.
Should files within the second-level package be able to see symbols within
its including package?

-- app.ex
with package
package atom app
include a.e
without package
...

-- a.e
...
with package
include b.e
without package
...

-- b.e
? app

It doesn't seem to me like a very sane thing to do, but you know that 
someone will try it.  I ask in the interest of trying to flesh out some
corner cases.

> I'm absolutely convinced that Chris' implementation is far to complex to be
> useful or used. I cannot see the need for "with package" etc ... 

Yeah, I'm concerned about its complexity, too.  Now that we have a better
namespace and symbol resolution system, this is more about encapsulation
for its own sake (generally a good thing) than about fixing actual problems
that people have.

> Matt wondered how to use a maths package from two different 'vendors'. Simple!
> 
>    include derek/math.e as dp
>    include matt/math.e as ml
> 
>    ...
>    a = dp:abs(x)
>    b = ml:abs(x)

My questions were really assuming that we were somehow 'inserting' symbols
into specific packages, and that it would be meaningful to give them 
names.  Part of my thinking (which I admittedly hadn't fully explored)
was about how the parser would handle this sort of thing.

> And I can't see how keeping all the files of a package supplied by a single
> vendor in the same directory is wierd or unusual.

My concern was more that once we go down this road, we *have to* keep 
these things in separate directories or risk breakage.  I'd prefer to
stay away from such a solution if possible.

Matt