Sho Kuwamoto

Glad you see the light! I posted a similar topic about a year ago...

http://www.darronschall.com/weblog/archives/000149.cfm

Dido

http://softwareaddiction.blogspot.com/2005/10/public-property-keep-out.html

The problem with Java is that you have to write over-engineered code

Great article, Darron, and thanks for the link, Tiago.

That is what is cool about AS. In Java classes i started doing it also, for quick value transfer objects and internal classes that shuttle data back and forth between requests and such.
Too bad the style checker on the project forced me to rewrite it...

I am doing a lot of Ruby now as well, and there it is the same (as you can leave off the ( ) in a method call. so one also have the benefit that later on one can change it without refactoring a lot of code.

But honestely, with eclipse and intelliJ, what is wrong with some refactoring. As long you know you are not working on a API or some infrastructural part, how big is the chance, really, that later on you decide to hide a public member and instead handle it with a getter... and what is so bad in refactoring then...

really, i tend to become more and more pragmatic about this kind of thing...

Totally agreed, Ilya, although it does depend on the size and nature of your project. For a one person Java project, refactoring is not a problem. For a project with lots of team members, or with an interface that may be used by other people, refactoring is sometimes not practical.

It never occured to me that Ruby's optional parentheses amount to the same kind of freedom. (I've never actually written a program in Ruby) Thanks for that insight.

Sho ... I agree so much with you, I'll write that in a book 18 months ago :-) Excerpted from the book:

Value Object Accessors

In J2EE, we would likely encapsulate our attributes as private attributes, with public getters and setters,
but in ActionScript, we recommend that you consider the following strategy that we adopt at
iteration::two.
In the simplest case in which we expect to be only getting or setting attributes, we choose to declare
the attributes as we’ve just shown, with public variables. Setting or getting attributes on a value
object is then as simple as this:
var account:AccountVO = new AccountVO();
account.accountNumber = “00310712”;
mx.core.Application.alert( “Account Number is “+account.accountNumber );
If the requirement on our value objects becomes more complex; perhaps we can do something a little
more clever in setting an attribute, for instance. Then we can encapsulate it by adding getter and
setter methods for the attribute.
5666 CH20 4/14/04 10:30 PM Page 23
24 Chapter 20 Flex Integration with J2EE
In ActionScript 2.0, we can use a feature known as implicit getters and setters and perform the following
refactoring:
public get accountNumber():String;
public set accountNumber( account:String )
{
this._accountNumber = “RN/”+account;
}
private var _accountNumber:String;
In this refactoring, we change the access of our accountNumber attribute from public to private, and
rename the attribute. (At iteration::two, our convention is to prefix with an underscore, although
many Macromedia classes use underscores in their implementations—and the compiler might warn
you if you happen to clash.) We then use the notation for an implicit getter and setter function, with
our function containing the same name we had for our public attribute. This then ensures that the
following code calls our setter—the implicit getter and setter ensure that a function call is treated as
if it were an attribute:
account.accountNumber = “00310712”;
In the preceding example, our motivation for the refactoring is shown as a requirement that
account numbers be prefixed with the fixed length string “RN/”.
This refactoring allows us to migrate from public attributes to public implicit getters and setter,
without affecting any client code (code that performs gets or sets).
We recommend this strategy over coding your own Java Bean style getters and setters.

Glad to see us agreeing on something !

hmm, the cfm seems to have a hard time handling unicode...

Steven: Great comments. Thanks. BTW, you and I know that we agree on things more than we disagree. :-)

I agree