It *is* for Shell Petroleum :) But, point taken because I don't think the project I'm working on is going under the .com domain. I copied some classes from a previous project which was under the .com domain without even thinking about changing the package names. Slap self on wrist!!
Also, mental note to self to remove direct references to clients from future posts! I usually do, not because I'm secretive but I'm sure clients would prefer their developers didn't mouth off about in-progress and as yet unreleased projects! Thanks André for your suggestion - I'll give it a bash. A. On 8/25/06, Mike Keesey <[EMAIL PROTECTED]> wrote:
PET PEEVE ALERT class com.shell.util.IntroAnimProxy Unless you are actually doing Shell Petroleum's website at http://shell.com, this isn't a proper name for the package. The "com" convention is a strategy to keep package paths from overlapping on different projects: if you're doing a website, you take the domain and reverse it--voila, you have a path that nobody else will ever use, and you don't ever have to worry about conflicts. (Assuming everyone sticks by the convention, of course.) I've even seen people make classes like "com.MyClass", as if "com" stood for "component" or something. (It stands for "commercial".) If you're not working on a website project, then you have a couple of options: 1) Make a new package for the project in your own domain's package. (e.g., "net.mywebsite.mynewproject") or your client's domain package. Even if it's not going on the web, you can still guarantee it won't conflict with any other packages. 2) Make a package that doesn't start with any top-level domain strings ("com", "org", "net", country codes, etc.) I'll own that in this instance you'll only really have a problem if, some day, you *do* work on http://shell.com, but still.... (And if this *is* for Shell Petroleum, then I'll shut up now.) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrés González & Aragón Sent: Friday, August 25, 2006 9:29 AM To: Flashcoders mailing list Subject: Re: [Flashcoders] Singleton not always Singleton? The problem i can see is tha in the singleton pattern constructor must be private. May be triin with something like this : class com.shell.util.IntroAnimProxy { private static var _instance:IntroAnimProxy; public static function get instance():IntroAnimProxy { if( _instance == null ) _instance = new IntroAnimProxy(); return _instance; } private function IntroAnimProxy() { trace("IntroAnimProxy"); } } _______________________________________________ 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
_______________________________________________ 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
