On 8/22/07, Ron Wheeler <[EMAIL PROTECTED]> wrote: > > > Ian Thomas wrote: > > > Your second example is overcomplicated - why teach getters and setters > from > > the word go when a property (public var age:Number;) is far simpler/more > > obvious? Yes, getters and setters are part of the OOP paradigm, but not > a > > requirement. > > > > > That was my example. You teach people the right way to do it so that > they never consider addressing a property directly. It may look easier > but someday, it will break your code in a way that will cause you a lot > of grief. There are good reasons why it is not done. > > Not addressing properties is a requirement of OOP otherwise you break > encapsulation.
I think my head is in AS2/AS3 world, where you're dealing with instrinsic getters and setters, i.e. the AS2/AS3 syntax. Which, personally, I find a much better solution than the Java getters/setters. But that's a conversation for another day. :-) You're right, my example was bad practice. But at a higher level than Java, it is perfectly permissible to have public properties in OOP. It's just that, in Java, a property called 'Age' is accessed via 'obj.getAge()', in AS3 it's obj.age via 'function get age()', when talking to a Bean via BSF it's just obj.age, when reading a data structure it's just obj.age, in PHP it's $obj->age and so on. Properties exist and are legal to talk to - look at any OOP-based API. :-) OOP, at a basic level, consists of objects, methods _and_ properties - and my argument is that mainstream programming is all converging on that model and that's why it should be taught. But properties aren't public member variables, which is where my example was wrong. :-) Ian _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com