Charles C wrote:
> Ben Chambers <ben### [at] pacificwebguycom> wrote:
> 
>> That's worse than having no standard, because then you have to check
>> whether or not its standardized...
>>
>> My opinion is, you make a standard, and stick to your guns.  People are
>> still free to make their own files, and distribute them the
>> old-fashioned way, so noone's really losing anything.  But for such a
>> collection to be useful, standards are the way to go.
> 
> 
> I think it all depends on what we're building here.  Something like a
> professonal product containing the best of the best, or a community effort
> containing some things that might not be as up-to-snuff as others.  If this
> were a for-sale package, it'd be most professional to have everything be as
> uniform as possible.  On the other hand, if it were up to me I'd like to
> think of this thing to be a little more inclusive.  I think we'll be hard
> pressed to find a single standard that won't turn most people away.  So,
> I'd lean more towards guidelines, and tutorials on how to make #includes
> "nice," kinda like what Chris B was talking about.
> 
> Charles

My reasoning for a well worded standard was because I was picturing this
becoming something like a STL for POV-Ray. When picking and choosing
certain includes, overlaps in variable and item names might not show up.
But we can't test every possible combination and they will show up
eventually.

This doesn't mean we can't have 'submitted includes' and 'standard
includes'. If this all falls under an open source license then we can
always fall back on the old 'if you want a non-standard include to work,
change it yourself.' Call them beta includes, even put them in a
separate zip file just to keep them apart. That way, anyone who wants to
put their code into this package can without editing anything if they do
not want to.

Post a reply to this message