OpenEuphoria

Re: Packages

• Posted by Derek Parnell <ddparnell at ?igpo?d.com> Aug 09, 2007
• 510 views

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.

In other words, I see it that a package is an arbitary set of files that all
have access to specific identifiers, which are defined in the package and
explictly designated as package-sharable.

If this is the case, the only two things to establish is how to designate which
files are in a given package, and which identifiers in a package are
package-shareble.

I thought that an operating system's file system would be a simple and effective
mechanism for grouping files. Especially seeing that's one thing a file system is
designed to do anyway. So my idea was that all the files in a given directory
would be deemed a package. The thing with links is immaterial. So what if a file
"appears" to be in two separate directories! That would just mean that the file
is in two separate packages. So what?

Now remember that the purpose of having these packages is so that they can
access package-shareable identifiers. If they are not doing that then they are
just simple include files. This means that the author of a package is
deliberately architecting the package to contain shared identifiers.

Which brings me to the next point. We need to explictly designate which
identifiers are shareable. I suggest the new keyword "package", which is used in
a similar manner to "global". This also means that include files that currently
exist (before this new keyword is implemented) would have to be modified if they
want to use this functionality.

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


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 ...

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)

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.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell