Re: Packages
Pete Lomax wrote:
>
> Matt Lewis wrote:
> >
> > > the package name is a full expanded path and filename.
> >
> > This just seems to be a portability nightmare to me.
>
> Huh? Is there some new OS out there which does not have paths & filenames?
> I honestly cannot think of any reason why that raised a portability issue.
Well, there's the slash issue, but of course, that can be dealt with.
However, some file systems are case sensitive, and others are not. I
believe that most people stick with all lowercase, but this is certainly
not a requirement. Again, not unsurmountable (after all, the same issue
is present when including a file). Nevertheless, as far as I'm
concerned, it's creating ways to fail when (I believe that) there are
other ways to accomplish the same goals without these drawbacks.
I probably used the wrong word. But it just seems too fragile to me,
since if any of those things change in relation to EUINC or each other,
the packaging is easily destroyed. Not so much portability across
OSes, but between people. The author of an application that uses a
library might prefer to distribute the app with all of the source files
in a single directory. Or organize his includes differently.
You might argue (and on a different, but similar issue, Derek already
has) that as end users, we should follow the end user's intent to keep
these things packaged, and in your case, that would mean following his
path structure. It also seems more difficult to maintain than it needs
to be.
I suppose that part of my goal here is to enrich the language without
adding new constraints about the way it's used. And I think that in
this case we can accomplish this, but not the way you've proposed.
> > Also, I still don't
> > see the need for having an actual package name as a global symbol.
>
> I only percieve package names as global in the sense that in parser.e the new
> routine doPackage() has a permanent list of ones it has seen before.
Yes, that's what I meant. But to me this just begs for package naming
conflicts.
> > It
> > just means that you have to wrap your packages with another file, rather
> > than sprinkling the package declarations throughout them. This has the
> > bonus that it's easy to see what's in there, rather than searching through
> > the files.
>
> Now I'm confused: what "It" means that, and who said it?
> AFAIK, I'm the one arguing against "directory" and "file" as the scope, while
> leaving the latter as the default by auto-closing at eof.
Sorry. 'It' refers to defining packages in the way (or equivalent) Derek
proposed.
> Here is another ficticious scenario:
> 1) file.e and machine.e want to share some private data for a new RTFatal
> style
> error incorporating machine info and last file access details.
> 2) file.e and database.e want to share some buffer pointers etc for a new
> flush(-1)
> or flush_all() statement.
> Obviously as with all trivial examples it would not really matter if you had
> to throw all this in the same pot, but it ought to be more scaleable.
> It seems harder to me to divide the data up like that with a "file list"
> mechanism
> than a "private scope xxx" one. With the former you might have to duplicate
> the entire list in multiple files whereas with the latter you would only have
> to repeat the "xxx" name.
>
> I can see that a "package filemach,filedb" could be useful to declare a
> private
> item in file.e which is visible to both machine.e and database.e although
> other
> stuff in "filemach" is not visible to database.e and other stuff in "filedb"
> is not visible to machine.e. I can also see that an explicit "end package" and
> multiple package directives in the same file could be useful, I never actually
> ruled that out but then again I never actually said as much either.
>
> This all seems quite trivial and maybe even elegant in my head, although I can
> tell it is not getting across like that 
It never does, does it. :)
On the one hand, I can see the benefit of having the package declaration
right in the file where you're using it, cluing you in to look for
private symbols in other files. But that's not really any different
than global variables, and from within a file, there's no way to know if
an external symbol is global or private, so I don't think that argument
holds a lot of water.
On the other hand, using something similar to Derek's method defines all
of the files in the packages in one place, so there's no need to search
through lots of files (and still maybe not be sure that you found them
all). And by using this method, we've removed the requirement (I think)
for adding a new category of things with names to clutter up the namespace.
Matt
|
Not Categorized, Please Help
|
|
