@barneyb, maybe I'm just being a curmudgeonly Java engineer, but it
still gives me the creeps to see all those public members. I see your
point, though. By using the implicit getters and setters only as
needed I can change the functionality without changing the "signature"
of the class. This seems to assume, however that most setters are
simply {this.myVar = myVar;}, and are actually a waste of time. I'll
concede that many of them may be, but they're generated, and I don't
actually have to write them. I see the value, in a shared-code
environment of being able to add the setter without having to update
calling code.
@Paul, We're using BlazeDS with Tomcat, and it's the same way... It
expects the AS class to have the public properties. But that seems to
me to be more of a response to the established convention rather than
something that's inherent to the AMF communications. They could
just as easily used a Beans kind of approach and retrospected the
class for set*() and get*(). Doesn't Mach-ii do that on its beans?
Anyway, thanks guys, nice to at least hear a well-reasoned response
to the question I actually asked. Usually when I bring this up the
answer I get is, "You want setters? Just write 'em, and leave me
alone!"
/w
On Tue, Nov 10, 2009 at 1:33 PM, Paul Kukiel <[email protected]> wrote:
>
> As well as for VO's back to ColdFusion they need to be public.
>
> Paul.
>
> -----Original Message-----
> From: Barney Boisvert [mailto:[email protected]]
> Sent: Tuesday, November 10, 2009 3:32 PM
> To: flex
> Subject: Re: AS convention: Public member variables?! What of encapsulation?
>
>
> ActionScript, unlike Java, lets you transparently override public
> properties with implicit getters and setters. So you can start with a
> public property, and then later decide to use a getter/setter pair
> without changing the API of your class. With Java, you can't do that,
> so you HAVE to declare the getter/setter pair up front.
>
> As a concrete example:
>
> public class Person {
> public var name:String;
> }
>
> can be used like this:
>
> p = new Person();
> p.name = "fred";
> trace(p.name);
>
> Later, you can change the class to this:
>
> public class Person {
> private var _name:String;
> public function get name():String {
> return _name;
> }
> public function set name(name:String):String {
> _name = name;
> }
> }
>
> After doing that, you can still reference the class in exactly the
> same way as before; ActionScript takes care of the implicit
> getter/setter magic internally, so you don't have to worry. The net
> is that you're not sacrificing encapsulation, you're just not having
> to write a bunch of boilerplate code until you actually need to.
>
> cheers,
> barneyb
>
> On Tue, Nov 10, 2009 at 12:18 PM, Willy Ray <[email protected]> wrote:
>>
>> Ok... I'm not asking "can I use getters and setters to properly
> encapsulate my AS classes?". I'm asking why does the accepted ActionScript
> convention seem to be public member variables? Every example I see, every
> book I buy... public properties all the time.
>>
>> Aren't we Flex developers just as worried about uncontrolled access to
> these members as, say, Java developers? Is there some feature of the
> language that I'm missing that protects against bad data being set into
> public properties?
>>
>> /Willy
>>
>>
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Want to reach the ColdFusion community with something they want? Let them know
on the House of Fusion mailing lists
Archive: http://www.houseoffusion.com/groups/flex/message.cfm/messageid:6185
Subscription: http://www.houseoffusion.com/groups/flex/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.37
