How do I create Package Methods in Flex?
In ColdFusion, if I put a bunch of ColdFusion Components (AKA CFCs) in the same directory it is called a package. I can create methods with the cffunction tag that has "access=package". This means that the method can be called by the CFC that defines it, CFCs that extend the defining CFC, and other classes in the same package.
How do I implement the same behavior in Flex?
First I want to make sure you understand that a CFC in ColdFusion is a parallel to a class in ActionScript. ColdFusion does not have any way, code-wise to distinguish the package of a class. ActionScript does. When creating a class, you use the package keyword:
[imports]
[metadata]
[class definition]
}
In ActionScript if the package name does not match the directory, you'll get compiler errors; but the statement has to be there nonetheless. In MXML, the Flex compiler takes care of creating the package statements, so you don't have to manually specify it.
Anyway, back to the topic of this post. Assuming I've created two classes in the same package, how do I create a package method? In CF I use "access=package" (I said that already). The most common Flex access modifiers are public, private, and protected. None of those will do what is needed. There is another modifier keyword named internal . The code would be something like this:
return "foo";
}
It took a bit of doc searching to find out how to do this. It is worth noting that the keyword can be used on constants and variables also. The documentation says that the items are put in the internal namespace by default, but if you leave it out the compiler throws a warning.
*Normally* you would only have one, public, class in a given package though. I can't understand why you wouldn't break out these 'internal' classes ?
The Flex framework has plenty of packages w/ more than one public class. Controls is a prominent example: http://livedocs.adobe.com/flex/2/langref/mx/contro... ).
Having a single public class in a given package does not negate the need for internal methods (or variables, const, or namespaces ).
I'm not sure what you mean when you say "I can't understand why you wouldn't break out these 'internal' classes." I didn't say anything about internal classes (only methods).
mx.controls is many seperate files, each having one public class (with no package-only methods, only some mx_internal), isn't it ?
I agree it doesn't negate the need, I didn't mean to infer that.
It doesn't matter if their internal classes or internal methods - why would you close those off to people extending your component (with internal rather than protected) in a way that isn't 'private' ?
I have created two classes that work together, conceptually similar to how DataGrid and DataGridColumn might work together. I wanted the "TopClass" to be able to communicate with the "ChildClass" while not exposing that method to any old user.
Private or Protected won't do it, which lead me to internal.
I have not had to deal with subclassing the stuff I'm working on, but you're right that is an issue that may come up later and I'll have to explore.