ps we're probably not the first ones discussing this old subject, has n1
found some good sources/references?
Most of the old CS textbooks sentence you to hell for using public variables
so let's not refer to those ;)
On Wed, Dec 10, 2008 at 8:28 AM, Hans Wichman <
[EMAIL PROTECTED]> wrote:
> Hey,
>
> I'm not against using public variables, but I dont like using get set as
> you did below *if *setting the data has sideeffects outside the area of
> validation.
> If you are setting a property and you want to test or verify it or
> whatever, I can imagine using set get.
> If you are setting a property and it causes state changes or whatever I
> like to use an explicit method. Yeah you can mouse over it, codeinspect it
> or whatever and see it's an implicit get/setter, but just looking at an
> interface I find it easer to have either public methods or properties and
> not something in between that lends itself to misuse (ie this set data WAS
> only validating, but damn now it needs to change state as well, ah heck,
> lets cram in there instead of ....)
>
> So for me it's usually either a public var or a method.
>
> And there's more behind it than good coders being forced to work with bad
> coders at least as far as the public variables are concerned, it has to do
> with the whole mumbo jumbo of the OO asking versus simply taking. An object
> giving access to its internals instead of an object grabbing access,
> although in a lot of cases it doesn't pay to make such an academic
> distinction.
>
> I liked the clear explanation Steven gave, although comparing it to
> masturbating sounds a bit like promoting it ;0)
>
> JC
>
>
>
>
> And a *big* +1 for this:
>
>>
>>
>> That being said, I don't abide by the retarded rule that you shouldn't
>>> have public vars in a class.
>>>
>>
>> regards,
>> Muzak
>>
>> ----- Original Message ----- From: "Steven Sacks" <
>> [EMAIL PROTECTED]>
>> To: "Flash Coders List" <flashcoders@chattyfig.figleaf.com>
>> Sent: Wednesday, December 10, 2008 5:01 AM
>> Subject: Re: [Flashcoders] use get / set functions or make your own
>>
>>
>> For clarity, they're referred to as implicit and explicit.
>>>
>>> get prop / set prop = implicit
>>> getProp() / setProp = explicit
>>>
>>> In AS2, it made a difference because implicits were available right away,
>>> whereas explicits were not available for 1 frame. This limitation is not
>>> present in AS3.
>>>
>>> Basically, implicit implies properties of a class, whereas explicit
>>> implies methods of a class.
>>>
>>> I opt for implicit over explicit because this:
>>>
>>> foo.prop = value;
>>>
>>> makes more sense than
>>>
>>> foo.setProp(value);
>>>
>>> I leave methods for methods, not properties.
>>>
>>> That being said, I don't abide by the retarded rule that you shouldn't
>>> have public vars in a class. People who do this
>>>
>>> private var _foo:Boolean;
>>> public function get foo():Boolean { return _foo; }
>>> public function set foo(value:Boolean):void { _foo = value; }
>>>
>>> are masturbating and I'm not impressed by their bloated ego...I mean
>>> code. ;)
>>>
>>> Unless something needs to happen immediately within the class when you
>>> set or get a prop (i.e. a state change), it's fine for it to be a public
>>> var. It's faster, it's less bloat and most of us aren't writing large
>>> applications with a bunch of other developers. Some of these rules were
>>> created for when good coders are forced to work with bad coders and the good
>>> ones need to protect their code from the bad ones. When it's just you and a
>>> couple other devs, and you're all competent, you don't need all these checks
>>> and balances that are nothing more than compensation for people who you wish
>>> you didn't have to code with. /rant ;)
>>>
>>>
>>>
>> _______________________________________________
>> Flashcoders mailing list
>> Flashcoders@chattyfig.figleaf.com
>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>
>
>
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
