Paul King wrote, On 09/08/2003 15.45:
...
For include the conceptual model is one of textual inclusion
(or XML entity inclusion if you are that way inclined).
The ant way states (at least for properties) that whoever sets
things first wins. I would argue that would be the simplest
model for
Jose Alberto Fernandez wrote:
From the XSLT bible by Michael Kay (2nd edition page 232):
Like inheritance un object-oriented languajes, xsl:import is designed
to allow the creation of a library or reusable components, only in this
case, the components are modules of stylesheets. And the
Costin Manolache wrote:
IMHO ant should try to be a bit easier to use than XSLT.
I was playing with some examples to capture the use cases
which have been discussed for include and import with a view
to getting a/some simple models straight in my head.
I am attempting in part to explain the use
Jose Alberto Fernandez wrote:
One of the problems I have with the rewriting approach is that target
names get rewritten y the caller which means that two independent
importers may decide to use the same prefix and hence you get a clash.
Namespaces or java-style fully-qualified-names are a
Jose Alberto Fernandez wrote:
I don't know _any_ programming language where import is used for
inheritance.
Believe it or not, XSLT is a programming language. :-)
And it uses the term import for inheritance.
I know XSLT is a programming language, I don't remember it beeing an OO
language.
Nicola Ken Barozzi wrote:
Yes, most build files have a target named build - but I don't know why
would you think about inheritance and OO instead of just qualified names.
I don't know _any_ programming language where import is used for
inheritance.
Well, I pointed out xslt, what about
Trying to summarize.
Costin Manolache wrote, On 08/08/2003 16.21:
Nicola Ken Barozzi wrote:
...
As has been pointed out in these threads, Ant is a different beast, and
should be treated differenty.
+1
We are talking about OO concepts and inheritance - in import context.
Well, we are not. We are
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
One of the problems I have with the rewriting approach is
that target
names get rewritten y the caller which means that two independent
importers may decide to use the same prefix and hence you
get a
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Nicola Ken Barozzi wrote:
Yes, most build files have a target named build - but I
don't know why
would you think about inheritance and OO instead of just
qualified names.
I don't know _any_ programming language where import is
Jose Alberto Fernandez wrote, On 08/08/2003 20.02:
...
From the XSLT bible by Michael Kay (2nd edition page 232):
Like inheritance un object-oriented languajes, xsl:import is designed
to allow the creation of a library or reusable components, only in this case,
the components are modules of
Thanks for the overview, Nicola !
Just to get you up to speed, the current issue is about multiple
inheritance, and how the current system allows cross-import (unwanted?)
side-effects, as Conor has brilliantly shown.
What I'm not sure I understand is what import has to do with multiple
Costin Manolache wrote, On 07/08/2003 4.43:
Thanks for the overview, Nicola !
Just to get you up to speed, the current issue is about multiple
inheritance, and how the current system allows cross-import (unwanted?)
side-effects, as Conor has brilliantly shown.
What I'm not sure I understand is
Nicola Ken Barozzi wrote:
Thanks for the overview, Nicola !
Just to get you up to speed, the current issue is about multiple
inheritance, and how the current system allows cross-import (unwanted?)
side-effects, as Conor has brilliantly shown.
What I'm not sure I understand is what import
Just to get you up to speed, the current issue is about multiple
inheritance, and how the current system allows cross-import (unwanted?)
side-effects, as Conor has brilliantly shown.
What I'm not sure I understand is what import has to do with multiple
inheritance :-)
Because we can
Some comments on the issues inside:
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Costin Manolache wrote, On 07/08/2003 4.43:
- add possibility of prefix in import declaration
import file=xxx prefix=xxy/
This would work as a qualified name ?
I think basically yes, but
Sorry if the mail becomes long, I have difficulty in deciding what to
snip ;-)
Costin Manolache wrote, On 07/08/2003 15.56:
Nicola Ken Barozzi wrote:
Thanks for the overview, Nicola !
Just to get you up to speed, the current issue is about multiple
inheritance, and how the current system allows
Jose Alberto Fernandez wrote, On 07/08/2003 16.15:
Some comments on the issues inside:
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
...
Well, IMHO I personally don't see a real, strong, compelling
reason to
have targets have crosstalk between themselves, but I do have
an equally
strong
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Nicola Ken Barozzi wrote:
I don't know _any_ programming language where import is used for
inheritance.
Believe it or not, XSLT is a programming language. :-)
And it uses the term import for inheritance.
Well, KISS is my concern as
Knut Wannheden wrote, On 07/08/2003 16.13:
...
Maybe it would be better to think in the term of mixin as some languages
(e.g. some Lisp flavours and Ruby) use. The following two exerpts are from
the Modules chapter of the free book Programming Ruby: The Pragmatic
Programmer's Guide
Jose Alberto Fernandez wrote:
First I do not think I have all the answers, just to keep things in
perspective. What I think I have is a set of principles that I think any
viable solution should provide. Lets see if I can put them into words: ;-|
1) I should be able to determine the
Costin Manolache wrote, On 06/08/2003 6.44:
...
One think I don't understand is why the import should be used as a OO
substitute. Most languages I know define the import in a much simpler
way. Maybe I'm missing too much of the context, I'm still trying to get
updated with the mailing lists.
Just
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Costin Manolache wrote, On 06/08/2003 6.44:
...
One think I don't understand is why the import should be
used as a OO
substitute. Most languages I know define the import in a
much simpler
way. Maybe I'm missing too much of the
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
1) I should be able to determine the correctness (loosely
used here) of a
buildfile by looking at that buildfile (and its dependencies) in
isolation. This means that the fact that I am imported by
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
All the resolution of the semantics of the language is done
before name mangling
This is not strictly true. In C++ you decide (by using extern
C) whether
to place a symbol in the global namespace or its own (by name
mangling). The
What stops you from writing two separate buildfiles one for each
that perform the import and do the respective override. From your
main build you just ant/ these new files.
Probably nothing, especially in this particular example. However, not only
should I not have to do that, there will be
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
On Fri, 1 Aug 2003 10:47 pm, Nicola Ken Barozzi wrote:
How can this thing be done while shielding interactions?
You make the renaming optional.
import file=a.xml/
import file=b.xml/
All of a's and b's targets go unprefixed. If those
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
What stops you from writing two separate buildfiles one for each
that perform the import and do the respective override. From your
main build you just ant/ these new files.
Probably nothing, especially in this particular example.
Just to mention, name mangling in C++, IIRC, is not for the code writer
consumption. It is for the mapping of the code to the symbol tables
of the C compilers and linkers below.
I think we are pushing the whole OO analogy for Ant a little too hard. Ant
build files are not class definitions,
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
On Fri, 1 Aug 2003 04:20 am, Jose Alberto Fernandez wrote:
Given the nature of ANT, I think it may be really important
to be able
to specify super in the dependencies of the overriden method.
I think part of the problem on this issue i
Jose Alberto Fernandez wrote, On 01/08/2003 11.40:
...
OK, lets get on the nitty gritty of the matter. :-)
What do you mean by unrelated imports? If they are unrelated why do you need to
import them toghether? Why don't you use ant/ to call between the unrelated
targets? In other words, the now
On Fri, 1 Aug 2003 07:40 pm, Jose Alberto Fernandez wrote:
OK, lets get on the nitty gritty of the matter. :-)
What do you mean by unrelated imports? If they are unrelated why do you
need to import them toghether?
They may be unrelated because they are written by different people.
I will
Conor MacNeill wrote, On 01/08/2003 12.27:
On Fri, 1 Aug 2003 07:40 pm, Jose Alberto Fernandez wrote:
...
On the other hand, if you have to import them, then it is because they have
to share something or one defines some target for the other, or something.
I disagree. Importing them into a common
On Fri, 1 Aug 2003 10:47 pm, Nicola Ken Barozzi wrote:
How can this thing be done while shielding interactions?
You make the renaming optional.
import file=a.xml/
import file=b.xml/
All of a's and b's targets go unprefixed. If those builds use targets which
are provided by the main build,
I totally agree with everything you in this post Conor ;-) --DD
-Original Message-
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 5:28 AM
To: Ant Developers List
Subject: Re: override
On Fri, 1 Aug 2003 07:40 pm, Jose Alberto Fernandez wrote:
OK
-Original Message-
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 9:24 AM
To: Ant Developers List
Subject: Re: override
On Fri, 1 Aug 2003 10:47 pm, Nicola Ken Barozzi wrote:
How can this thing be done while shielding interactions?
You make
Dominique Devienne wrote, On 01/08/2003 17.14:
-Original Message-
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 9:24 AM
To: Ant Developers List
Subject: Re: override
On Fri, 1 Aug 2003 10:47 pm, Nicola Ken Barozzi wrote:
How can this thing be done while
-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: override
and that renamed targets from a and b should not be
call-able directly from the command line, but only from within the build
.
Keep up the good work.
-Original Message-
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 9:24 AM
To: Ant Developers List
Subject: Re: override
On Fri, 1 Aug 2003 10:47 pm, Nicola Ken Barozzi wrote:
How can this thing be done while shielding interactions
Subject: Re: override
import file=a.xml prefix=a/
import file=b.xml prefix=b/
override target=a.init
antcall target=b.init/
/override
Thoughts?
Conor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Dominique Devienne wrote, On 01/08/2003 17.38:
-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: override
and that renamed targets from a and b should not be
call-able directly from the command
Dominique Devienne wrote, On 01/08/2003 17.58:
On second though, instead of renaming, why don't we use IDs, which are
common and well understood:
Well, they have a special meaning in XML and I would not use them for
this feature. It also spoils consistency with other ant namings, as
usually we
Looks interesting.
Cheers,
Antoine
- Original Message -
From: Conor MacNeill [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 2:07 PM
Subject: override
I'd like to take a slightly different angle on the import issue by
getting
some thoughts on this little
Conor MacNeill wrote, On 31/07/2003 14.07:
...
I think with a renaming import task this would let you override any part of
the build easily.
Very cool indeed :-)
[I'd like to thank all the ones that are discussing on import. Very nice
posts and constructive stuff, I love you guys :-)]
It seems
On Thu, 31 Jul 2003 10:23 pm, Nicola Ken Barozzi wrote:
The only thing that comes to mind is that I cannot use super ion
dependencies, which is a nifty feature :-(
Not sure why this would be needed. Just add super/ as the first contained
task. All of the other dependencies will have been run
, and didn't see isreference. After the
discussion I had with Stefan, I thought it was there... Did I misunderstand,
or is it just not documented.
-Original Message-
From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 7:29 AM
To: 'Ant Developers List'
Subject: RE
On Thu, 31 Jul 2003, Dominique Devienne [EMAIL PROTECTED] wrote:
PS: I checked the online manual, and didn't see isreference.
It's in the manual for CVS HEAD but not the online manual (as
isreference is not part of 1.5.x).
Stefan
+1 for override[-target]
+1 for include as import without target override sematics
On Thursday 31 July 2003 15:25, Dominique Devienne wrote:
PS: I checked the online manual, and didn't see isreference. After the
discussion I had with Stefan, I thought it was there... Did I
misunderstand, or
Conor MacNeill wrote, On 31/07/2003 15.44:
On Thu, 31 Jul 2003 10:23 pm, Nicola Ken Barozzi wrote:
The only thing that comes to mind is that I cannot use super ion
dependencies, which is a nifty feature :-(
Not sure why this would be needed. Just add super/ as the first contained
task. All of the
On Thu, 31 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
+1 for include as import without target override sematics
+1
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
peter reilly wrote, On 31/07/2003 16.41:
+1 for override[-target]
+1 for include as import without target override sematics
+1 for both here too.
Maybe getting those working and combining them can make us see what/if
extra functionality is needed for an import.
Since in Centipede I do not use
Dominique,
Indeed ;-) What you demoed Conor is precisely the use case I
need, which was
very much inspired by Knut's past posts. I also like Knut's
override-target name better, as it's more explicit.
The one thing I'm not too sure about is the override-property and
override-path ones...
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
On Thu, 31 Jul 2003 10:23 pm, Nicola Ken Barozzi wrote:
The only thing that comes to mind is that I cannot use super ion
dependencies, which is a nifty feature :-(
Not sure why this would be needed. Just add super/ as the
first
52 matches
Mail list logo
