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