Can't say as I ever heard of Scott. :)

Back in my college days I wrote my own language for compiler construction
class... one of the decisions I made was that functions never actually
return values, they alter parameters.  You had to specify whether each
parameter was an "input" parameter or "output" parameter, and input
parameters were implicitly final in the scope of the function (although
you could copy it to another variable of course).  Maybe that's where I
got the in thing from :)

It was kind of neat in some ways... you could do something like:

Direct Output To Screen
Declare a As int= 5
Declare b As int = 3
Declare result As int
Call doMyMath(in a, in b, out result)
Display result // Shows 16 on the current output device, now the screen
End
Function doMyMath(in number1, in number2, out theAnswer)
  // number1 now has the value of a,
  // number2 now has the value of b,
  // and neither can be directly altered in this function.
  // theAnswer is a variable scoped to this function and
  // is essentially an alias for result, so because it is
  // defined as an out parameter, altering it will alter
  // the variable it aliases, result in this case.
  theAnswer = (number1 * 2) + (number2 * 2)
End Function

Clearly it was an overly verbose language, and had some flaws that I
didn't recognize at the time, but it was still kinda neat in some regards.

And your right about what some IDEs emit to... in the greater scheme of
things I don't think this represents any kind of big problem, or even a
problem at all.  Not in the realm of a bean anyway... any time you have a
method that actually does more work than a simple mutator, then you
generally do want to be careful of variable shadowing, but I hardly think
it's a big deal in a mutator like this.  Like I said, I do it the way I do
more to just avoid the analysis errors (yeah, I know I could turn them
off, but I want as much as possible to be caught in general).

Ok, it's Friday, I'm leaving for the day.  OT reply to OT post ends now :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Fri, July 1, 2005 3:37 pm, Leon Rosenberg said:
> You must be scott ambler fan :-)
>
> Or maybe not, he suggests words like a, an, some
> public void setValue(int aValue){
>       value = aValue;
> }
>
> In his coding conventions...
> http://www.ambysoft.com/javaCodingStandards.html
>
> Regards
> Leon
>
> P.S. don't blame anyone for using this.x = x too fast, it's often
> generated
> by ides, even eclipse did it in one of the versions.
>
>> -----Ursprüngliche Nachricht-----
>> Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
>> Gesendet: Freitag, 1. Juli 2005 21:19
>> An: Struts Users Mailing List
>> Cc: Struts Users Mailing List
>> Betreff: Re: [OT]java bean question
>>
>> Since this thread was marked as OT, I figured I'd contribute
>> an OT reply :)
>>
>> It is worth noting that the syntax...
>>
>> this.someProperty = property;
>>
>> ...is usually flagged by static code analysis tools because
>> the incoming parameter shadows that of the class.  True,
>> using "this" disambiguates (is that a word?!?) the reference
>> and no harm is done.  I myself used to use that syntax all the time.
>>
>> However, I've gotten into the habit of doing...
>>
>> public void setSomeProperty(String inSomeProperty) {
>>   someProperty = inSomeProperty;
>> }
>>
>> ...if for no other reason than to avoid the extra errors
>> emitted by CheckStyle and the like.
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> On Fri, July 1, 2005 3:21 pm, [EMAIL PROTECTED] said:
>> >
>> >>From the javabean spec this is acceptable.  However, it is
>> not good
>> >>coding
>> > standards to have a property in all upper case.  The java standard
>> > naming convention has constance as all upper case,
>> properties as camel case.
>> > Struts would have a problem with this because it is looking for the
>> > first letter of the property to be lowercase.
>> >
>> > if this is a procedure name it would be better to have the
>> parameter
>> > as either p813name or procP813NAME.
>> >
>> >
>> >
>> >              Ashish Kulkarni
>> >              <kulkarni_ash1312
>> >              @yahoo.com>
>>             To
>> >                                        user@struts.apache.org
>> >              07/01/2005 02:54
>>             cc
>> >              PM
>> >
>>        Subject
>> >                                        [OT]java bean question
>> >              Please respond to
>> >                "Struts Users
>> >                Mailing List"
>> >              <[EMAIL PROTECTED]
>> >                   he.org>
>> >
>> >
>> >
>> >
>> >
>> >
>> > Hello
>> > I have java bean where in there is one property as below private
>> > java.lang.String P813NAME ; public void setP813NAME
>> (java.lang.String
>> > P813NAME ) { this.P813NAME = P813NAME; } public java.lang.String
>> > getP813NAME () { return this.P813NAME ; }
>> >
>> > is this valid or not?
>> > if not why not and where i can find specification for java bean
>> >
>> > Ashish
>> >
>> > __________________________________________________
>> > 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]
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to