Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 2340 invoked from network); 13 May 2005 13:13:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 May 2005 13:13:42 -0000 Received: (qmail 46675 invoked by uid 500); 13 May 2005 13:17:56 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 46609 invoked by uid 500); 13 May 2005 13:17:56 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 46593 invoked by uid 99); 13 May 2005 13:17:56 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from mallard.propagation.net (HELO mallard.propagation.net) (66.34.7.1) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 13 May 2005 06:17:56 -0700 Received: from h1.int.eeaston.com (12-218-234-39.client.mchsi.com [12.218.234.39]) by mallard.propagation.net (8.9.3p2/8.8.5) with ESMTP id IAA14711 for ; Fri, 13 May 2005 08:13:31 -0500 Received: from [192.168.0.80] (g5 [192.168.0.80]) by h1.int.eeaston.com (Postfix) with ESMTP id 607F039826 for ; Fri, 13 May 2005 08:13:27 -0500 (CDT) Message-ID: <4284A7FE.4050000@eeaston.com> Date: Fri, 13 May 2005 08:13:34 -0500 From: Evan Easton Reply-To: apache@eeaston.com User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Developers List Subject: Re: [Bug 28444] - Import: Target Handling Bug References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Anyone consider: ... Nicola Ken Barozzi wrote: > Jose Alberto Fernandez wrote: > >> Going to the old discussions in how to approach this issues, >> the thing that bother me most, is that in order to get access >> to an imported target I need to know the name given to the project >> on the file that did the import. >> >> This in my opinion contradicts the hidding rules of OO programming. >> I should not need to know about the internals of an imported object. >> It also means that I have to coordinate all the files I may directly >> or indirectly import so that there is no project name clashes. > > You could make the argument that the name isn't really an internal. It's just an alias to reference the project since using the filename might not be desirable. Java and some other languages base the name of a class or module on the file or require the two to be the same. But what about C++, and probably others. You can declare whatever classes you want in a .h file with any name and yet you still expect the user to include some "file name" (e.g. ) and then use classes defined inside that file which may hve difference names (e.g. stringbuf, ostringstream,...). Some of the information defined inside the imported build file has to be accessible to the outside. It seems reasonable that, just like the target names, macro, presets, tasks, selectors, properties, .... the project name could be one more piece of useful information. You just now have to be careful not to rename the project if others might be importing your build file....just like any resource, in any imported/included file, is virtually any language. Evan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org