binarycloud-dev

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

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

Alex:

Shucks.

Here I sit down tonight to revise my modules to make them
run in the latest r2 with ubiquitous Makefiles.

Shucks.

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

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.

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.

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.

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

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

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

[Odysseas T. <ody...@ya...>]

> path separator), kills me.  Why?  Because I, in my
> world,
> use:
> 
> 	*.layout	for layout template files
> 	*.master	for master templates files
> 	*.mod		for modules

As we are evolving BC towards the more makefile-driven
r2, we decided to standardize the various file type
extensions:
Makefiles need standard extensions so as there
are standard rules that can do one thing for one type
of a file and a different thing for another type of a
file. That's why if you write your C application
you are stuck ending all your files with .c etc etc.

> 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...

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. 

The packaging feature become a necessity
as you move from small software projects to big ones.
Languages that were built from the begining for large
scale programming, like Java, had that feature from
birth. 
Languages like perl, in their original versions
allowed any extension and lacked the packaging
functionality. As the perl applications became deeper
and deeper the packages were introduced. To use the
packages you had to name your files *.pm . 
In some ways PHP is like perl in its infancy. Projects
like BC are trying to enable its use not only for
web-site-making but also for more heavy duty web
applications and in that sense are forced to make use
of some of these more "advanced" features. 
 
odysseas

> 
> 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.
> 
> _jef
>  


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

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

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

> As we are evolving BC towards the more makefile-driven
> r2, we decided to standardize the various file type
> extensions:
> Makefiles need standard extensions so as there
> are standard rules that can do one thing for one type
> of a file and a different thing for another type of a
> file. That's why if you write your C application
> you are stuck ending all your files with .c etc etc.

I suppose you could enable some sort of "file translation directory" as an
include for the make system - where if a user wants to say ".master = .php",
they can.

I don't particularly love that, but I believe it would work, no?

> The packaging feature become a necessity
> as you move from small software projects to big ones.
> Languages that were built from the begining for large
> scale programming, like Java, had that feature from
> birth.

This is an important point. We're talking about managing a very large
codebase, and working with that codebase in development.

In my first version of Page, there were includes - and those includes were
path based and a little kludgey.

Now those includes are imports, and they are structured, clean, and
readable.

If we're going to use external libraries of code like Pear, Metabase, etc we
need a way to handle updates, etc to those - and I would prefer not to deal
with having to update include_once statements all over the place. Packages
make everything a hell of a lot cleaner.

Also, by standardizing filenames, we can do things like allow you to have
entities in module directories in the source tree, but make sure all the
entities are in one place in the build version.

All of that is only possible if we can have some implicit knowledge about
the files in the make system. I can imagine that 'filename' directory, but
at the same time that's a maintenance headache for whoever is doing
development. But that may be the solution.

> Languages like perl, in their original versions
> allowed any extension and lacked the packaging
> functionality. As the perl applications became deeper
> and deeper the packages were introduced. To use the
> packages you had to name your files *.pm .
> In some ways PHP is like perl in its infancy. Projects
> like BC are trying to enable its use not only for
> web-site-making but also for more heavy duty web
> applications and in that sense are forced to make use
> of some of these more "advanced" features.

yepp

_alex

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

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

I think I should make this clear, so everyone know how this is going to
happen:

The releases I am doing right now of r2 are, while functional, almost
experimental. I'm playing. Nothing major will change, in the sense that I
don't intend to rename the project "CowPharm" and change the directory
structure :) - but at the same time all these early CVS snaps are just that:
pictures of a moving target.

These releases are not meant to be even remotely final, i.e. they are not
rigid statements about "how it will be" - they are "how it is now, but it
could change!"

So, this is not about policy, I don't ship policy. All of this stuff is
moving, and when we're done it will accomodate almost any changes, strange
configs, etc that everyone needs.

For the moment I'm concerned with getting a working system, even if it lacks
a few things - so we can take that and add flexibility and power.

I am being _extremely_ careful not to design in any restrictions - not to
say that there aren't assumptions in the current cvs snapshots (as Justin's
previous mail points out) - but to say that there _will_not_ be high level
assumptions unless there _absolutely_must_be_ to have a functioning system.

i.e. we all have to agree that modules are loaded by Page - but not
necessarily how to always name files, or how to run your make + development
process.

In the end all of this back and forth, and _early_ exposure to the community
(i.e. all of you) will help me judge how to proceed. It's extremely helpful,
and I thank you all for it. (Keep on crackin' the whip, justin :)

_alex

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

[Alby L. <al...@th...>]

Hey Justin,

You've been drinking too much coffee man, I thought I was bad getting up at
4:30am, starting work at 7, then finishing at 9:30pm.

You've got me beat: a post on Friday night @ 10:30pm; then another @ 6:50am,
on SATURDAY! Take it easy man, don't burn out!

Alby Lash
al...@th...

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

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

Alby:

Thank you for your concern about my health.  Don't worry,
the FBI Witness Protection Program is so efficient.  I
am such a hot number that they have put me up in the
orbiting space station.  So, those time stamps rotate
at Schuler Pendulum periods, 24, count 'em, every
82 minutes....


-------------------------

Alby Lash wrote:
> 
> Hey Justin,
> 
> You've been drinking too much coffee man, I thought I was bad getting up at
> 4:30am, starting work at 7, then finishing at 9:30pm.
> 
> You've got me beat: a post on Friday night @ 10:30pm; then another @ 6:50am,
> on SATURDAY! Take it easy man, don't burn out!
> 
> Alby Lash
> al...@th...
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

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