On Thu, 1 Jul 2004 08:01:21 +1000, Andrew Scott <[EMAIL PROTECTED]> wrote: > If Macromedia wishes to use that as a standard that is fine, then macromedia > should then remove that scope from existence!
Macromedia *Web Team* standard says don't use it. Macromedia *product team* added the feature. That's exactly the same situation as Sun and pretty much every compiler vendor: the language has the feature but 99% of coding standards say don't use it. > And if you have a company standard that is good, but lets say you had a job > opening and I came along and applied but choose to see execution time as a > bigger benefit would I not get hired because I don't see your full point? If you refused to follow the team's coding standards then, yeah, you wouldn't be hired. I think that's true of most (all?) companies. > Now to claim that Macromedia DON'T use the this scope is a very big > statement I know you can not back up. I'm talking about the Macromedia Web Team (whose coding standards are published on LiveDocs). Your comment made me go check the coding standards and, interestingly, they don't actually forbid "this" scope but I know that the engineers all know not to use it. Not using public data members is something so fundamental that it is second nature to them (because they mostly have OO backgrounds and know not to use public data from their experience with other languages). > In either Coldfsuion or your Java > programming I bet if I looked hard enough I could show you thousands of > examples where you do! Their Java programming guidelines are not published on LiveDocs - they're based on Scott Ambler's "Writing Robust Java" and here's a quote about this topic: "Using Accessors Writing Robust Java Code makes an important structural recommendation (3.4 The Use of Accessor Member Functions) that bears highlighting: use accessors instead of directly manipulating data members or class constants. According to this recommendation, the only methods that should directly access a data member are the accessor and mutator for that data member. All other references within the class should use the accessor / mutator. It follows that all data members will be private and accessors and mutators will generally be private or protected. Only if direct access / update for a data member is genuinely needed outside the class will the accessor and/or mutator functions be public. The other important consequence of this recommendation is that instead of class constants (static final data members), provide an accessor for flexibility. See 3.4.2.2 Getters for Constants for more detail." I'd be very, very surprised to see public data members in any of their Java code. As for the CF code, well, a lot was written against 6.0 which forced you to use "this" scope because "variables" scope didn't work. Some of that legacy code has been reworked to use "variables" scope, some hasn't - due to time/resource constraints. Sean --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
