You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Martin van den Bemt <mv...@mvdb.com> on 2001/01/02 20:45:18 UTC
Additions changes to the taskdefs.
Hi,
I'm pretty new to this (let's say "funky") open source stuff..
I'm now using Ant for whatever I can think of (even copying files ;-))..
I ran across a couple of problems :
- It throws an exception when the sourcedirectory is present.
I added an Error attribute which you can set to Ignore and will ingore the
error
- You put in chmod , but not chown, chgrp. I added those two and added an
extra Chrights, with everything in it. Just works for Unix btw...
It's pretty simple stuff to make and there's probably a good reason not to
put it in. Please let me know if it's intersting enough to submit it in some
kind of way. (or just mail it so someone).
I'm not a member of the maillingst yet, because at this moment I'm not able
to handle more e-mail (ehhh busy times in the "internet era"). Please CC me
for now when it concerns this mail... (thanx..)
I use the jakarta stuff a lot, so I like to submit changes/addition to
sources I make. If there are resources needed in any specific area, let me
know....
Now a coding question :
In some (didn't check them all btw). The init of an instance variable is
done with this.Blabla = "bla";
Only in the code this.Blabla is never used, only Blabla (it works I know..).
Is it just my horrible view on programming or it "nicer/neater" to use
this.Blabla anywhere to reference the instance variable?
(I'm using a lot of the same variable names (bad in thinking one up, and the
dummy1, dummy2 isn't very descriptive) and using the this. is pretty nice
then).
Let me know what you're opinion about this is..
Mvgr,
Martin van den Bemt
mvdb.com (ehhhh please don't go to this site, it's horrible for you
browser....)
Re: Additions changes to the taskdefs.
Posted by James Duncan Davidson <du...@x180.net>.
On 1/4/01 2:58 AM, "Peter Donald" <do...@apache.org> wrote:
> Actually usually it is immutables that have the UPPER_CASE notation of
> which static final primitive types are a subset.
So, should I mark my Strings with UPPCASE notation since, they are
technically immutable (even if I can move the reference)? :) (just to be
clear, that was a joke).
> Most theory is based around what I call cognitive programming. Your eyes
> should never travel more than 2 lines above current line and 3 lines below
> and you should never have to stop typing. All variables should be full
> names or "well known shortcuts" which means none of those miss the vowels
> or shortening of names ;)
Names should be explanatory, yes.
>> potentially accessed from anywhere in your system as is possible when using
>> oo languages with less enforcement of encapsulation where you can cheat and
>> call things that should be private just because you can.
>
> nope - most OO theory saids objects should never expose member attributes
> so that is irrelevent.
I'm not talking about OO theory. I'm talking about OO implementations
(especially ones with direct pointers) where you can call methods that are
supposed to be private without having the compiler or linker complain.
>> And for those of you worried about the performance drag of method calls,
>> Hotspot optimizes most bean methods out to simple variable accesses at
>> run-time when possible -- so avoids any performance penalty.
>
> And even on non-hotspot machines marking the accessor methods as final will
> achieve the same for older VMs (I think 1.7+ ???).
Marking the accessor as final will have a performance improvement on almost
any VM (by some degree). However, it's still a method call. The time savings
is taken by not having to check in any other place to see if the method is
overloaded.
However, marking methods final for performance reasons is silly in this day
and age. :)
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Additions changes to the taskdefs.
Posted by Peter Donald <do...@apache.org>.
At 02:45 4/1/01 -0800, James Duncan Davidson wrote:
>On 1/3/01 4:53 PM, "Peter Donald" <do...@apache.org> wrote:
>
>> Moderately modern research in developement environments that are relative
>> prone to iteration (ie virtually every modern oo dev-environment) indicate
>> that you should ALWAYs mark scope.
>
>I don't think all research indicates that. Some does, obviously.
ahhh ... check again. While not ALL research does virtually all modern
research (within last 7 years or so) does.
>> Each is roughly equivelent however Suns approach requires the programmer to
>> think. They have to know which variables are members and which are locals
>> etc and worse they can shoose to ignore it and get lazy.
>
>Actually, using the strictest guidelines from Sun along with the JavaBeans
>model means that you *never* expose instance or member variables to the
>public or even package scopes. Only protected (sometimes) or (usually)
>private scope. (exception to this is public static final CONSTANTS which
>have their own allupcase notation).
Actually usually it is immutables that have the UPPER_CASE notation of
which static final primitive types are a subset.
>Therefore, instance names only have to be remember in one file
bing ! The light goes on ;)
Most theory is based around what I call cognitive programming. Your eyes
should never travel more than 2 lines above current line and 3 lines below
and you should never have to stop typing. All variables should be full
names or "well known shortcuts" which means none of those miss the vowels
or shortening of names ;)
I spent about 3 months researching all this junk for a company and had the
help of a retired psychologist who specialized in psycho-physics help me
debunk the research. Most of it was utter trite biut there was some decent
research done .. most of it on IBM employees for some strange reason ;)
>potentially accessed from anywhere in your system as is possible when using
>oo languages with less enforcement of encapsulation where you can cheat and
>call things that should be private just because you can.
nope - most OO theory saids objects should never expose member attributes
so that is irrelevent.
>This means that the
>need to mark things out with names is very much reduced. I'd argue that it's
>reduced to the point of not needed. Everything possible should be a method
>call to get that variable so that maximum benefits from encapsulation are
>preserved.
right.
>And for those of you worried about the performance drag of method calls,
>Hotspot optimizes most bean methods out to simple variable accesses at
>run-time when possible -- so avoids any performance penalty.
And even on non-hotspot machines marking the accessor methods as final will
achieve the same for older VMs (I think 1.7+ ???).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Additions changes to the taskdefs.
Posted by Stefan Bodewig <bo...@apache.org>.
Hi Martin,
Martin van den Bemt <mv...@mvdb.com> wrote:
> I couldn't compile the latest ant sources, starting at the point
> when the build shell scripts were saying "File not found" before
> doing anything (ran across this once and solved it by redoing the
> bash file again)
What do you mean by "redoing the bash file"?
bootstrapping the latest sources works for me on Linux. Does
bootstrap.sh have the execute permissions set?
>>- You put in chmod , but not chown, chgrp. I added those two and
>>added an extra Chrights, with everything in it. Just works for Unix
>>btw...
> I wanted to implement them in the latest version you had online, but
> see above. I can implement it in the "official" source release of
> 1.2 if that's sufficient.
No, please send patches against latest CVS versions whenever possible.
> btw Do I just e-mail you the sources or is there a public cvs add /
> commit possibility?
Please see <http://jakarta.apache.org/site/getinvolved.html>. Send
your patches (and new files) here.
> Should I also make an effort to get this running under windows NT?
<chmod> checks os.name to make sure it is running on a Unix (like)
system. I think for a starter your tasks should do the same.
On the other hand there have been a lot of people complaining that
<chmod> wouldn't do anything on Windows - if you know how to achieve
the same functionality on Windows (I wouldn't know, but I claim to not
know Windows frequently) adding this support would be much appreciated
of course.
Stefan
RE: Additions changes to the taskdefs.
Posted by Martin van den Bemt <mv...@mvdb.com>.
Pete,
I'm pretty much a "self" made programmer (my high school diploma says :
bookkeeper) and because of that I didn't develop any of my own "programming
rules" (ehh it has to work is the one rule I have ...). And by being a
"self" made programmer, I had to use of other peoples code to get things
working... and I learned to adjust my programming to the code I'm working
on. I think for projects like apache, jakarta and so on it's best to adjust
to the code already there (ehhh if any..) and for new stuff I use sun's way
(or a little bit my own way...).
At 08:45 2/1/01 +0100, Martin van den Bemt wrote:
>I'm pretty new to this (let's say "funky") open source stuff..
>> welcome
thanx.. I completely rely on you guys (use almost everthing from apache.org,
if I got it running that is..)
>I'm now using Ant for whatever I can think of (even copying files ;-))..
>I ran across a couple of problems :
>> me too ;)
I couldn't compile the latest ant sources, starting at the point when the
build shell scripts were saying "File not found" before doing anything (ran
across this once and solved it by redoing the bash file again) If you have
any ideas, please let me know.. (just been using linux for a year now, so
this could be a "beginners question". btw I did a cvs checkout to get the
latest sources, the latest tars seemed to be dissapeared from the download
area
>- You put in chmod , but not chown, chgrp. I added those two and added an
>extra Chrights, with everything in it. Just works for Unix btw...
>> send em in if you want - Someone will eventually get around to adding
them
>> - I have never had a use for chown or chgrp because usually I don't run
any
>> scripts with said permissions but if you need/want it then .... ;)
I wanted to implement them in the latest version you had online, but see
above. I can implement it in the "official" source release of 1.2 if that's
sufficient. Please let me know. btw Do I just e-mail you the sources or is
there a public cvs add / commit possibility? Should I also make an effort to
get this running under windows NT? (gone back from 4 to 1 nt box now, so
hurry with this answer, before everything is linux ;)). Users probably need
a MS resourcekit command-line to change the rights, so it's not a "fail
safe" solutions I think..
Mvgr,
Martin
Don't get yourself killed while typing..
Re: Additions changes to the taskdefs.
Posted by James Duncan Davidson <du...@x180.net>.
On 1/3/01 4:53 PM, "Peter Donald" <do...@apache.org> wrote:
> Moderately modern research in developement environments that are relative
> prone to iteration (ie virtually every modern oo dev-environment) indicate
> that you should ALWAYs mark scope.
I don't think all research indicates that. Some does, obviously.
> Each is roughly equivelent however Suns approach requires the programmer to
> think. They have to know which variables are members and which are locals
> etc and worse they can shoose to ignore it and get lazy.
Actually, using the strictest guidelines from Sun along with the JavaBeans
model means that you *never* expose instance or member variables to the
public or even package scopes. Only protected (sometimes) or (usually)
private scope. (exception to this is public static final CONSTANTS which
have their own allupcase notation).
Therefore, instance names only have to be remember in one file -- not
potentially accessed from anywhere in your system as is possible when using
oo languages with less enforcement of encapsulation where you can cheat and
call things that should be private just because you can. This means that the
need to mark things out with names is very much reduced. I'd argue that it's
reduced to the point of not needed. Everything possible should be a method
call to get that variable so that maximum benefits from encapsulation are
preserved.
And for those of you worried about the performance drag of method calls,
Hotspot optimizes most bean methods out to simple variable accesses at
run-time when possible -- so avoids any performance penalty.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Additions changes to the taskdefs.
Posted by Peter Donald <do...@apache.org>.
At 08:45 2/1/01 +0100, Martin van den Bemt wrote:
>I'm pretty new to this (let's say "funky") open source stuff..
welcome
>I'm now using Ant for whatever I can think of (even copying files ;-))..
>I ran across a couple of problems :
me too ;)
>- You put in chmod , but not chown, chgrp. I added those two and added an
>extra Chrights, with everything in it. Just works for Unix btw...
send em in if you want - Someone will eventually get around to adding them
- I have never had a use for chown or chgrp because usually I don't run any
scripts with said permissions but if you need/want it then .... ;)
>In some (didn't check them all btw). The init of an instance variable is
>done with this.Blabla = "bla";
>Only in the code this.Blabla is never used, only Blabla (it works I know..).
>Is it just my horrible view on programming or it "nicer/neater" to use
>this.Blabla anywhere to reference the instance variable?
>(I'm using a lot of the same variable names (bad in thinking one up, and the
>dummy1, dummy2 isn't very descriptive) and using the this. is pretty nice
>then).
>Let me know what you're opinion about this is..
Well there is 4 different ways to mark variables
1. Scope
2. Name
3. Type
4. Access modifier
Which ones you choose depends on your particular domain. You will find that
most GUI develoeprs use 2 + 3 so you get variable names like
startAction
startButton
startPanel
etc.
A lot of c developers and other non-OO languages (like basic SQL-DB) use
2+3 with that foul hungarian notation like "szFirstName"
Moderately modern research in developement environments that are relative
prone to iteration (ie virtually every modern oo dev-environment) indicate
that you should ALWAYs mark scope. Reason is that it enables you to quickly
localize variables. How this is done is up to debate thou. Some IBM houses
use variable names like fAnInstanceMemberVariable, gAClassMemberVariable,
MS uses m_anInstanceMemberVariable, c_aClassMemberVariable while Sun uses
this.anInstanceMemberVariable, ClassName.aClassMemberVariable.
Each is roughly equivelent however Suns approach requires the programmer to
think. They have to know which variables are members and which are locals
etc and worse they can shoose to ignore it and get lazy. I belong to the
"religion" that believes programmers are generally stupid and need to be
protected from themselves and thus prefer explictness of IBMs/MSs approach.
The reason is that even the best programemr can make errors so why not safe
gueard against it ? I have been members of projects that went over
deadlines because of silly mistakes that could have been safeguarded
against so now I tend to run everything on pedantic mode ;)
I generally use MS over IBM as it messes less with cognitive processes -
most programmers "pronounce" variables in their head and the prefix without
the _ messes it up ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Additions changes to the taskdefs.
Posted by James Duncan Davidson <du...@x180.net>.
On 1/2/01 4:29 PM, "Conor MacNeill" <co...@ebinteractive.com.au> wrote:
> I tend to use this.blah only when blah by itself would be ambiguous. This is
> usually the case in the setter for blah and perhaps a constructor in which a
> value for blah is passed.
Yep. That's about where I stand as well. "this." is great when you need it,
and 5 extra characters to get in the way when you don't.
--
James Duncan Davidson duncan@x180.net
!try; do()
RE: Additions changes to the taskdefs.
Posted by Martin van den Bemt <mv...@mvdb.com>.
Thanx for the advice.... I never thought of aBlah, theBlah, etc... That life
could be this simple ;-))...
Agree with the _Blah... It's too much C.... and typing an _ isn't very
fast...
Sorry... This is getting a little bit out of topic I think..
Mvgr,
Martin
-----Original Message-----
From: Conor MacNeill [mailto:conor@ebinteractive.com.au]
Sent: Wednesday, January 03, 2001 1:30 AM
To: ant-dev@jakarta.apache.org
Cc: mvdb@mvdb.com
Subject: RE: Additions changes to the taskdefs.
Martin,
> Now a coding question :
>
> In some (didn't check them all btw). The init of an instance variable is
> done with this.Blabla = "bla";
> Only in the code this.Blabla is never used, only Blabla (it works
> I know..).
> Is it just my horrible view on programming or it "nicer/neater" to use
> this.Blabla anywhere to reference the instance variable?
> (I'm using a lot of the same variable names (bad in thinking one
> up, and the
> dummy1, dummy2 isn't very descriptive) and using the this. is pretty nice
> then).
> Let me know what you're opinion about this is..
>
Ahh, love those style questions.
My personal preferences:
I tend to use this.blah only when blah by itself would be ambiguous. This is
usually the case in the setter for blah and perhaps a constructor in which a
value for blah is passed. It saves me thinking up new variable names which
are usually contrived; something like aBlah, theBlah, newBlah, _blah, etc. I
don't like the use of this.blah everywhere. When I am reading the code for
an object (class), I like to "live" in it, to assume its context and
this.blah just becomes distracting. Nor do I like the use of _blah to
distinguish private fields but some would disagree (Simeon?).
Your religion may vary.
Conor
RE: Additions changes to the taskdefs.
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
Martin,
> Now a coding question :
>
> In some (didn't check them all btw). The init of an instance variable is
> done with this.Blabla = "bla";
> Only in the code this.Blabla is never used, only Blabla (it works
> I know..).
> Is it just my horrible view on programming or it "nicer/neater" to use
> this.Blabla anywhere to reference the instance variable?
> (I'm using a lot of the same variable names (bad in thinking one
> up, and the
> dummy1, dummy2 isn't very descriptive) and using the this. is pretty nice
> then).
> Let me know what you're opinion about this is..
>
Ahh, love those style questions.
My personal preferences:
I tend to use this.blah only when blah by itself would be ambiguous. This is
usually the case in the setter for blah and perhaps a constructor in which a
value for blah is passed. It saves me thinking up new variable names which
are usually contrived; something like aBlah, theBlah, newBlah, _blah, etc. I
don't like the use of this.blah everywhere. When I am reading the code for
an object (class), I like to "live" in it, to assume its context and
this.blah just becomes distracting. Nor do I like the use of _blah to
distinguish private fields but some would disagree (Simeon?).
Your religion may vary.
Conor