Menu
▾
▴
binarycloud-dev
|
From: alex b. <en...@tu...> - 2001-06-30 17:51:24
|
If I am correct, here's the list of issues:
-we need to be able to deal with multiple "named" user directories that
use the same binarycloud/ package tree. (I 100% agree, this will be done)
-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.
-Justin would also like to have the ability to name his files with
whatever extensions he likes. However, I just thought of something:
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.
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.
--------
If I missed anything, let me know.
_alex
|
|
From: Peter B. <re...@f2...> - 2001-06-30 20:34:02
|
At 10:48 AM 6/30/01 -0700, you wrote: > -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. I have to say I would also like to see it changed. To me, a dot represents a file extension or similar. Using, for instance, binarycloud:core:Perm shows me that it is a path to a module (or whatever) rather than a file with lots of extensions tacked on :-) Hope that's clear! Peter. -oOo- Maple Design - web design, hosting, domain names http://www.mapledesign.co.uk -oOo- |
|
From: Justin F. <je...@ey...> - 2001-06-30 23:12:23
|
alex black wrote: > > If I am correct, here's the list of issues: > > -we need to be able to deal with multiple "named" user directories that > use the same binarycloud/ package tree. (I 100% agree, this will be done) OK, I want this the most. #-- above item 1 -- I want this the most, to have "site-name" sub-trees at the /user level. > -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. 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". 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. > -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. > 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). #-- 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 really mean it, I am not just being nice. > -------- > > If I missed anything, let me know. > > _alex > > _______________________________________________ > 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 |
|
From: alex b. <en...@tu...> - 2001-06-30 23:44:08
|
> > -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 |
|
From: Alby L. <al...@th...> - 2001-07-02 12:58:26
|
It sounds as though the import, include, or include_once ( I can't remember which one this pertains to) delimiter problem has been solved, but I wanted to throw in that Flash, as an odd ball comparison, also uses dots in ActionScript to delimit objects: _root.parent.child._attribute and the like, so when you're not dealing with file names, it really kind of makes sense. One time when I did run into a problem with this was when I was trying to control an attribute of a child object with db driven data, I couldn't specify the object directly, or even the object hierarchy (_root.parent) from the database because it won't let me put dots into varchars. That, unfortunately, I am certain was my fault and not necessarily a flaw in the system arch. I also vote for _Dot Delimiters_. Hey - you just can't argue with alliteration. Alby Lash al...@th... |
|
From: Alex B. <en...@tu...> - 2001-07-02 17:49:59
|
I have no changes planned for the import delimiters - they will stay "." :) -a > It sounds as though the import, include, or include_once ( I can't remember > which one this pertains to) delimiter problem has been solved, but I wanted > to throw in that Flash, as an odd ball comparison, also uses dots in > ActionScript to delimit objects: > > _root.parent.child._attribute and the like, so when you're not dealing with > file names, it really kind of makes sense. One time when I did run into a > problem with this was when I was trying to control an attribute of a child > object with db driven data, I couldn't specify the object directly, or even > the object hierarchy (_root.parent) from the database because it won't let > me put dots into varchars. That, unfortunately, I am certain was my fault > and not necessarily a flaw in the system arch. > > > I also vote for _Dot Delimiters_. Hey - you just can't argue with > alliteration. > > Alby Lash > al...@th... > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X