--- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > > > The user's omission of the project> name > > > > implies consent to this. > > > Not quite. [...] > > I still don't see how this conflicts with my > > earlier statement. > > Where I disagree is that you assume the imported > build writer is the > same as the importer build writer (the user or > client in other words). > As a client, I shouldn't have to care whether the > project is named or > not, and be able to manipulate and reference the > build I import on my > terms, not his terms.
Point. However, in such a case it would not make sense for the provider of the imported file not to use a project name. Was there a reason not to support "as"? It sounds like a trivial change. If we supported "as", we could bypass storing project-name stuff for <import> unless "as" is specified, printing a warning as well. Then we change the documentation to recommend the use of the "as" attribute, with your explanation as to why it is preferable. -Matt > > This is why it's still so difficult to write truly > generic build > files, despite <import>. Not enough > compartimentalization, and mixing > of concerns. --DD > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
