Re: [binarycloud-dev] list of make issues

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

> >     -Justin would like to see the package delimiter in import statements
> > change from . to something else that no one would ever think of using in
a
> > filename: : or :: or # or whatever.
> > I am not really opposed to changing binarycloud.core.Perm to
> > binarycloud:core:Perm, actualy - though I would like Odysseas' opinion
on
> > that one.
> #-- above item 2 --
> Actually, I have become agnostic on this.  You will have to
> understand my initial confusion on this facility. Alex is
> correct that I should use include_once().  For a while, I
> was hung up in my mind that Alex wished to "register" all
> er, includes for some reason that I did not understand,
> but PHP is going to do that for the work ot the user/module level
> within the include_once() facility, AND NOW I UNDERSTAND
> that Alex didn't want, or care about, what got done within
> modules, unless import() was used within the module.

Yes, cool.

> So, what I think is that the dot is probably the best
> separator here, simply because that this is the way
> Java does it, and it is considered the "standard way".

Correct, I far prefer (and am used to) package.subpackage.Class

> I certainly won't confuse it with a file name because
> these are pulling in classes, and BC requires that the
> file basename be the name of the class, so I ain't gonna
> ever be able to scatter dots around in module names unless
> BC finds another way to derive the class name from the
> file name which for MyClass.secondtry.php would mean that
> BC would have to go _inside the file_ to get the class
> name.  I wouldn't even do that to my enemies.

Correct.
I waswilling to entertain : because that's how perl does it (actually,
Foo::Boo)

> >     -Justin would also like to have the ability to name his files with
> > whatever extensions he likes. However, I just thought of something:
> #-- above item 3 --
> See below
>
>
> >     Justin, are you only interested in having that ability within the
tmpl/
> > directory in user?. We have to establish a standard for entity naming,
> > because they will be interpreted by the make system and moved around at
> > build time, for example - but we may be able to just "assume" that
> > everything under tmpl will be a template, and thus only need language
> > keying.
> #-- above item 4 --
> Yea, I find it more important to have it for masters and layouts
> than for modules.  I would certainly rather have it operative
> for templates to have *.masters and *.layouts, and I would
> willingly forego any wish for *.mod for modules, because,
> er, modules _are_, er, "php" in my head.

That is a possibility.

> > Putting the above aside, the only way I see to allow for
developer-defined
> > extensions is to create a file with extension -> type mappings that make
> > uses to determine file type at build time.
> >
> > for example:
> >
> > ".master" = 'php'
> > ".layout" = 'php'
> > ".phtml" = 'php'
> >
> > etc.
> >
> > Again, I don't necessarily object to that, but Odysseas is the make
expert
> > among us, and I would like his opinion.
> #-- above item 5 --
> This would be cool, that mapping.  On some rainy day, I will
> start analyzing the Makefile system, see if I could come up
> with what I want as a superset of the present system, and if
> it is truly easy, I'll give you my ideas.  From my previous
> postings, you probably realize that I love to fiddle with make(1).

That _might_ be the case, but to be honest my experience with make is quite
limited.
I wouldn't mind that, either... actually, I sort of like it. I.e. if for
whatever reason you need to have a certain extension treated a certain way,
there would be a means of doing it without hacking the makefiles.

> #-- not above item 6 --
> You have been silent on dots scattered in file names (templates).
> Look, I can live with, get used to, stop complaining, if I just
> do my templates, for my convenience, for my admin scripts like:
>
> sitename-layout-page1.php [if we get no *.layout accommodation]
> or
> sitename-page1.layout [if we get *.layout accommmodation]
> or
> sitename-master-page1.php [if we get no *.master ability]
> or
> sitename-page1.master [if we get a *.master accommodation]
>
> This means, I would rather have the extension capability than the
> dot-in-a-filename capability.  Heck, I can parse on the hyphen or
> underscore instead of this dot that is causing problems in filenames.

I believe we can add the extension capability to import with relative ease.
Integration into make is a more complex issue.


> I really mean it, I am not just being nice.


heh :)

_alex