[binarycloud-dev] File Extensions: My bark is worse than my byte...

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

Alex/Odysseas:

[off topic]
Odysseas, is your wife/girlfriend/SO named Penelope?

[topic]
It is good to see that the reason for the current mechanism
of forcing .php (but not .PHP) extensions is for noble reasons, i.e.,
for
the Java-like package thingy.  And, I also understand that
some of the background utilities like xml2php requires
extension determination, cause there ain't no way to look
at MAGIC_NUMBERS in text files or imbed artificial intelligence
into these utilities, and look inside before leaping.

OK, what can we do here?  You also must realize that the
present mechanism prevents me from using dots in file
names.  I will have, say, an additional problem that
may be useful to describe as I would hope that it
could be accommodated.  Here, Les Artistes (our design
department), being goog Mac users, like to give me
files that have names like:

	"The picture of Julie with a red dress"
	"jpeg of Julie with Daisy Dukes"

and I at least got them to do

	"The.picture.of.Julie.with.a.red.dress"

instead.

So, with BC, I could imagine in development Les Artistes
give me 10 layouts for some page that we must make a decision
on, like:

	Jean-Pierre.1.layout
	Jean-Pierre.2.layout
	Jean-Pierre.3.layout
	|

and we gather around to test them to make a choice.  I
have to either rename the files, or symbolic link each
one of them  file->test.php, one by one.

So, even if I train Les Artists to give me

	Jean-Pierre.1.layout.php
	Jean-Pierre.2.layout.php
	Jean-Pierre.3.layout.php

it ain't gonna work.  This conforms to the "specification"
denoted by Odysseas, viz:

--quote--
The package/import notation and functionality is
mimicking the package/import of java/perl etc.
As you have guessed, this feature puts an additional
requirement for a single source code extension.
--unquote--

but, friends, your import() would still choke on
it too...  So, this "requirement" is sort of
disingenuous, as the above set "conforms" but
doesn't work in these circumstances.

I could impose a Java-like, initial caps nomenclature
like:
	FileLayout1.php
	FileLayout2.php

which would work, but I too, would like to use the
old dot in the old fashion in the old way, cause I
may have a script or a Makefile that looks for
/*.layout$/, or /*.layout.*/ and does something with
this collection.

There has to be a way out of this.  I think your
conception of using "packages" is a good thing.
Hmm, I will have to think about how to do it,
while still allowing my beloved dots to be used
in filenames as fields that reflect some kind of
important information.class.use.owner.whatever.
The design assumption of mapping "dot" as a
one to manyUses is the basic "problem" here.
Now, a quick solution would be:

        'templates' => array(
                'def' => array(
                        'name' => "|Jean-Pierre.1.layout",
                        'package' => "html.masters",
                        'type' => "html",
                ),
                'other' =>  array(
                        'name' => "|Jean-Pierre.2.layout",
                        'package' => "html.masters",
                        'type' => "html",
                )

to use the pipe "|" to have import() know when the path
ends and the file begins.  BUT THIS IS RATHER UGLY.  I
allege that you probably have enough information already
to somehow work around.  YOU KNOW right now that in the
$bc_page hash,  what is in ['name'] IS A FILE, but without
the .php extension.

Like all insecure authors, I will leave the solution up
to the reader....

I'll come back to youse guys if I think of something
general and elegant.

Regards,
_jef


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