Significance of package names

2008-03-20

What is the significance of the package naming convention?

What is the difference between "flash" and "fl"?

An example of "flash" is flash.display
An example of "fl" is fl.controls

¤ ...challenge everything! (wink) ¤
...oh wait I don't work for EA anymore.

"My interest in usability arose from the pain and tears of patching the wounds of suffering interface designs with the inadequate bandages of help files and user guides." — Daniel Cohen

Nutrox · 2008-03-20 #2

Package names can be anything you want, but it is good practice to base the package names on a domain name structure especially if you intend to distribute any classes in those packages. In a nutshell it helps to avoid conflicts between two classes with the same name. Adobe are actually starting to do that now with their com.adobe.* package, I use com.neondust.*, and you might use com.holaso.* if you have the holaso domain name.

I think Macromedia/Adobe used the flash.* and fl.* package names because it makes things a lot easier when manually typing the package names in Flash, plus those classes are the core classes of the application. If I made a huge application called Fishy then I would probably just use the fishy.* package name instead of using com.neondust.fishy.*

Hope that makes some kind of sense.

Codemonkey · 2008-03-21 #3

There's no difference between flash and fl, other than readability. Don't forget you might not be the only one getting to see the code. Maybe you'll open source your stuff one day... maybe you decide to attract a friend on the project. You never know and even for your future self that looks back at the code would probably benefit from logical sounding package names (just the same as with class names and property names).

Like Nutrox said, there's a convention that you would use your domain reversed; it makes sure your class name (formally, package plus class' name) is unique all over the world. It also makes sure all your applications are structured the same way and can be put together without problem. If for example you put them all together, you would have all your applications located at d:\mystuff\flash\projects\org\houseofcode\*. Suppose you would start to use version control (svn, cvs, clearcase what have you) you can put all your projects in there in a consistent way, without having to worry about variable classpaths and stuff. Consistency is the key to enlightenment.

Aside from conventions, it is wise to use logical names for packages. In the java world for examples, there are some widely accepted package names that appear in almost every web applications.
For example:
org.housofcode.webbap.service
org.housofcode.webbap.dao (interfaces for data retrieval)
org.housofcode.webbap.dao.impl (if there are a lot of dao implementations, otherwise dump 'em with the interfaces)
org.housofcode.webbap.application (model for example)
org.housofcode.webbap.controller
org.housofcode.webbap.database
org.housofcode.webbap.domain
org.housofcode.webbap.util
org.housofcode.webbap.value (value objects to expose domain objects to the views)
etc.

So, for larger applications it is not only a matter of readability, but also a matter of manageability.

Another thing, for advanced developers, packages can be very important in regards to exposing classes and interfaces to the public. For example, you can make classes package protected so that users outside that package cannot use that class. An example is that you do have a public interface, but keep the implementations hidden from the users by making those package protected.

Then there is the matter of teamworking on package units and determining the size of packages in general. I've written a post earlier about an article I found on this topic, which I thought was very interesting:
Packages and granularity

Holaso · 2008-03-25 #4

Mostly I was wondering what Adobe-Macromedia had in mind with respect to functionality when they use "flash" vs. "fl" For example is "flash" more display oriented classes while "fl" is more control related classes? Is it simply an artifact of previous versions? Why were classes written in two different package sets?

Nutrox · 2008-03-25 #5

I have to take a wild guess here, but I imagine that has to do with distribution. For example, the "fl" package is geared towards Flash CS3 because of the timeline/keyframe related classes, that package isn't available in Flex Builder by default but if you have Flash CS3 installed then you can point Flex Builder at those classes. The "flash" package contains generic classes such as Sprite that can be used in both Flash CS3 and Flex Builder. Also, you will notice specific packages that are only available if you are creating a SWF file for AIR ( "flash.desktop" and "flash.filesystem" for example ).

Holaso · 2008-03-26 #6

ah THAT answers my question thanks!

Thread Tools
Show Printable Version Email this Page
Display Modes	Rate This Thread
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode	Rate This Thread:


	Ultrashock Forums > Flash > ActionScript • Significance of package names


		You are currently viewing our website as a guest which gives you limited access to forums, files and other resources. Click here to join now for free, and start interacting with our members, download files and much more! Click here if you are looking for our Flash files and other professional assets.

	Nutrox 17 Creative Assets	2008-03-20 #2
	Package names can be anything you want, but it is good practice to base the package names on a domain name structure especially if you intend to distribute any classes in those packages. In a nutshell it helps to avoid conflicts between two classes with the same name. Adobe are actually starting to do that now with their com.adobe.* package, I use com.neondust., and you might use com.holaso. if you have the holaso domain name. I think Macromedia/Adobe used the flash.* and fl.* package names because it makes things a lot easier when manually typing the package names in Flash, plus those classes are the core classes of the application. If I made a huge application called Fishy then I would probably just use the fishy.* package name instead of using com.neondust.fishy.* Hope that makes some kind of sense.

	Codemonkey	2008-03-21 #3
	There's no difference between flash and fl, other than readability. Don't forget you might not be the only one getting to see the code. Maybe you'll open source your stuff one day... maybe you decide to attract a friend on the project. You never know and even for your future self that looks back at the code would probably benefit from logical sounding package names (just the same as with class names and property names). Like Nutrox said, there's a convention that you would use your domain reversed; it makes sure your class name (formally, package plus class' name) is unique all over the world. It also makes sure all your applications are structured the same way and can be put together without problem. If for example you put them all together, you would have all your applications located at d:\mystuff\flash\projects\org\houseofcode\*. Suppose you would start to use version control (svn, cvs, clearcase what have you) you can put all your projects in there in a consistent way, without having to worry about variable classpaths and stuff. Consistency is the key to enlightenment. Aside from conventions, it is wise to use logical names for packages. In the java world for examples, there are some widely accepted package names that appear in almost every web applications. For example: org.housofcode.webbap.service org.housofcode.webbap.dao (interfaces for data retrieval) org.housofcode.webbap.dao.impl (if there are a lot of dao implementations, otherwise dump 'em with the interfaces) org.housofcode.webbap.application (model for example) org.housofcode.webbap.controller org.housofcode.webbap.database org.housofcode.webbap.domain org.housofcode.webbap.util org.housofcode.webbap.value (value objects to expose domain objects to the views) etc. So, for larger applications it is not only a matter of readability, but also a matter of manageability. Another thing, for advanced developers, packages can be very important in regards to exposing classes and interfaces to the public. For example, you can make classes package protected so that users outside that package cannot use that class. An example is that you do have a public interface, but keep the implementations hidden from the users by making those package protected. Then there is the matter of teamworking on package units and determining the size of packages in general. I've written a post earlier about an article I found on this topic, which I thought was very interesting: Packages and granularity

	Holaso	2008-03-25 #4
	Mostly I was wondering what Adobe-Macromedia had in mind with respect to functionality when they use "flash" vs. "fl" For example is "flash" more display oriented classes while "fl" is more control related classes? Is it simply an artifact of previous versions? Why were classes written in two different package sets?

	Nutrox 17 Creative Assets	2008-03-25 #5
	I have to take a wild guess here, but I imagine that has to do with distribution. For example, the "fl" package is geared towards Flash CS3 because of the timeline/keyframe related classes, that package isn't available in Flex Builder by default but if you have Flash CS3 installed then you can point Flex Builder at those classes. The "flash" package contains generic classes such as Sprite that can be used in both Flash CS3 and Flex Builder. Also, you will notice specific packages that are only available if you are creating a SWF file for AIR ( "flash.desktop" and "flash.filesystem" for example ).