Re: [binarycloud-dev] Warts on import() - bis

[alex b. <en...@tu...>]

> import('../../../bullshit');
> exit;

But that is not an import. You're trying to use it like include, which is
specifically what we're trying to avoid.

imports like:

binarycloud.core.Perm

are translated into paths:

binarycloud/core/Perm.php

for inclusion - and the paths adhere to our package structure (the paths in
source don't necessarily need to adhere to the package structure)

> Now Alex, you don't want THAT, do you?  You are not going to
> force policy of NEVER using relative directories, are you?
> Of course not, I hope.

If you want to use import, which uses _packages_ yes of course.
If you want to use a relative directory, do this:
include_once('../../moo/boo/whatever')
but I don't know where (or why) you would want to do that when you can do
user.mod.moo.Boo

> OK, I am not afraid of being laughed at for thinking out loud,
> so I have been thinking about "what you want to do" with this
> "package" idea, and the conventions you need to use for this,
> and how import() can be smarter.

I don't want to make it too smart, otherwise it sort of defeats the purpose:
a simple, clean bit of package infrastructure to help everyone deal with the
amount of code we have.

this import is about as standard as they come :)

> If import() is supposed to handle the abstraction of working
> for importing files, and/or "packages", and/or certain files
> from certain packages, ya gotta give import() more information.
>
> I think you should think about trying something like:
>
> import($_arg,$package=null)
>
> and then, cumbersome as it first appears, have the calling
> syntax require, if it is an "abstraction" from a package,
> call it thus:
>
> import("something_that_is_a_standalone_file")

There is no such thing. Import commands correspond to paths. So you can't
say "give me some file floating in space" - how would I know where to go and
get the actual thing in the filesystem?

> for a true file, and:
>
> import("something_related_to_package","package_name")
>
> for a "file" that is in the abstraction "package_name".

Again, I think you're trying to use import like include, and it doesn't work
that way :)

> You would have enough information available to import() to then
> be able to parse things and come out with the ultimate correct
> file to include_once().
>
> You might even wish to establish another global map to have
> tuples of "package" and "filename" held.  I don't know where
> you are going to go with those maps, I _do_ see their utility
> and efficiency of cutting down on useless calls to PHP that
> you know in advance are going to fail and burn up CPU time.

_exactly_ -> which is why we did not build an import that relies on a map,
which is a terrible waste of CPU cycles.

so, instead, we made the make process package our files for us, before
runtime, so we don't have to do inefficient lookups and other stuff like
that.

instead, import takes a package name:
binarycloud.core
and makes it a path:
binarycloud/core

> This is _only_ a quickie suggestion.  I have no inkling if this
> would fit in with your ideas.

all above :

_alex