binarycloud-dev

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

[Justin F. <je...@ey...>]

Alex:

Your import() is broken in any case.  You sent a dot when
you should have sent a man.

If I, for debugging purposes, change prepend.php as:

function import($_file) {
        global $sImportMap;
        if ($sImportMap[$_file]) { return true; }

        global $gImportPaths;
        // at some point we should extend this to enable a list of
import paths
        $gImportPaths = array(BC_PATH);

        $path = strtr($_file, '.', '/') . '.php';
        foreach ($gImportPaths as $prefix) {
printf("INCLUDED: %s<br>","$prefix/$path"); //<=== DEBUG
                if (include_once("$prefix/$path")) {
                        $sImportMap[$_file] = true;
                        return true;
                }
        }
        return false;
}

And then in the top of index.php, put these lines:

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

the result is:
------------------------------------------
INCLUDED: /usr/local/binarycloud/build/en//////////bullshit.php

Warning: Failed opening
'/usr/local/binarycloud/build/en//////////bullshit.php' for inclusion
(include_path='.:/usr/share/php') in ./prepend.php on line 34
------------------------------------------------

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.

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.

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")

	for a true file, and:

	import("something_related_to_package","package_name")

	for a "file" that is in the abstraction "package_name".

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.

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

Regards,
-- 
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722

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

[Andreas A. <a.a...@th...>]

Hi,

> And then in the top of index.php, put these lines:
> import('../../../bullshit');
> exit;

I think import() is not meant to handle path/fileinformation directly. What
you described is a side effect of import caus dots are translatet to / and
this way the import contains a meta info. But this might not be neccessarily
a path. (this should be fixed, disallow "/", "\" and .+).

The idea of import is a system to simplify including, I think (correct me if
I'm wrong):

E.g.: import('binarycloud.pear');

instead of:
include_once(BC_PATH."/ext/pear/PEAR.php");
include_once(BC_PATH."/ext/pear/cache.php");
include_once(BC_PATH."/ext/pear/whatever.php");
include_once(BC_PATH."/ext/pear/stuff.php");

The import() includes all neccessary files related to pear (or alle
neccesary files of pear you need to include by calling import(bc.pear), or
all files in the ext/pear/ directory or....). Imagine you have to include
all by hand and then some filenames change within pear, you have to edit all
your code where you include pear. With import, nothing changes.

Ok, you could do it the common way. But with a growing codebase the package
thing is more flexible, clear and intuitive, in my opinion.
And imagine it's required that individual tasks have to be perfomed by
including a specific package. If so you dont have to care about this, just
import package and thats it.

Andi

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

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

> I think import() is not meant to handle path/fileinformation directly.
What
> you described is a side effect of import caus dots are translatet to / and
> this way the import contains a meta info. But this might not be
neccessarily
> a path. (this should be fixed, disallow "/", "\" and .+).

The delimiter is "." at the moment, I think Justin wants to see that
changed.

> The idea of import is a system to simplify including, I think (correct me
if
> I'm wrong):
>
> E.g.: import('binarycloud.pear');
>
> instead of:
> include_once(BC_PATH."/ext/pear/PEAR.php");
> include_once(BC_PATH."/ext/pear/cache.php");
> include_once(BC_PATH."/ext/pear/whatever.php");
> include_once(BC_PATH."/ext/pear/stuff.php");

Correct.

actually:

import('pear.foo') - we're going to store pear and metabase (and anything
else) in the ext/ source dir.

> The import() includes all neccessary files related to pear (or alle
> neccesary files of pear you need to include by calling import(bc.pear), or
> all files in the ext/pear/ directory or....). Imagine you have to include
> all by hand and then some filenames change within pear, you have to edit
all
> your code where you include pear. With import, nothing changes.

Exactly.

> Ok, you could do it the common way. But with a growing codebase the
package
> thing is more flexible, clear and intuitive, in my opinion.
> And imagine it's required that individual tasks have to be perfomed by
> including a specific package. If so you dont have to care about this, just
> import package and thats it.

Again, exactly.

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