Re: [binarycloud-dev] Awwww man, facility, not policy!!!

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

> I don't get to first base.  Immediately, with the new gizmo
> as used in import() in the prepend, but also (evidently)
> in the parsing of th $bc_page hash, of substituting "/" for a dot
> (I suppose this is going to allow you to use the MS "\"
> path separator), kills me.  Why?  Because I, in my world,
> use:
>
> *.layout for layout template files
> *.master for master templates files
> *.mod for modules

ah, I did this for a number of reasons: I tried all the different extensions
in r1, and they ended up being annoying, not useful as I had oroginally
imagined.

Also, import works by taking package names, so you are talking about a path,
but it's better to think of import like:

binarycloud.core.Perm
which allows us to also do:

metabase.foo

and

pear.foo

for example.

> I am not going to justify myself (very much anyway),
> I just think that, BY INSPECTION, I know the "content"
> and/or the purpose of the file.  This is my policy.
> It avoids problems and confusion.  Now, you are
> forcing policy on me, you make me have _all_ my files
> end with ".php", WHEN THERE IS NO REASON TO.  These
> modules/layouts/templates are not in the DOCUMENT_ROOT
> where httpd _has_ to have known filename extensions.
> These files are down in the boiler room, conceptually,
> they have nothing, per se, to require a certain
> naming convention to operate properly.
>
> You have sinned, my son.

heh, but we need a way to differentiate between files that need to be
interpreted by xml2php from files that do not.

that means we must have a mechanism for doing that, which _at_the_moment_ is
by extension - and I don't see a really good way around that, short of
putting markers in files.

> Just to rub in a bit more salt, here is the conceptual
> "site", the "Hello World" site, and you have, in this
> package of files TWO files named example.php.  One
> is a master, the other is a layout.  You don't have
> to use much imagination to see the problems that
> could unnecessarily occur, a tarball, for example.
> Phooey.  Fiddlesticks.  Lordy.  Pox on ya.

But that's just my laziness, not a good counter example :)

also, yes, theoretically you could use

foo.master

and foo.layout
and

foo.mod
foo.lib
and
foo.foo

but that presents numerous other problems.
I _believe_ import will actually return a filename if it has a different
name than .php, after it looks for the .php... but I would have to look.

In any case it's not a big deal to do that, which would support most of what
you are talking about.

> At first, I thought this "dot" thing was kind of
> interesting when I started looking around.  I wondered
> if there was a refugee from the Xanadu project now
> working on BC...
>
> OK, I'll conform to your policy, for now, so I can
> keep going.  But I won't shut up on this one.  This
> is a real bitch, not gentle observation.

That import is very Java-like, which I prefer from the perspective of
structure.

Re: different extensions, I'm willing to entertain them but I prefer to use
directory structure rather than file extension wherever possible.

_but_ if I can come up with a good way to accomodate both ways of doing
things, I will.

_alex