Dumping the variables scope of a CFC gives you all the various methods that are a part of that CFC; which sometimes makes it hard to find what you want. That is why people adopted the variables.instance approach.

(Mike, I just started experimenting w/ your xml template for Enterprise Architect, and so far I’m liking it–good job)

J

Regarding the instance structure, while I wouldn’t say I’m super proficient in Java, it’s something I do work with with and have an academic understanding of, and there are quite a few things from Java that I try to follow when developing CFC’s. That said, instance variables are always just instance variables rather than being in their own map or something in Java, so it’s just one of those semantic nit-picky things I suppose. I guess it seems just as easy to dump the variables scope in a CFC to me? I also don’t find myself needing instance variables very often for anything other than objects since I usually pass around “beans” in CFC’s.

Regarding components in different paths– I usually try to follow a fairly rigourous directory structure so that I don’t end-up with one directory full of 60 unrelated components, and so that there aren’t any name collisions with anything else someone on my team might be working on. So for instance, here is an component directory structure that I’d probably follow (totally making this up on the fly):

\com\company\appname\dao
\com\company\appname\dao\DAOFactory.cfc
\com\company\appname\dao\ReportDAO.cfc
\com\company\appname\audio\AudioService.cfc
\com\company\appname\audio\SpeakerFactory.cfc
\com\company\appname\audio\Subwoofer.cfc
\com\company\appname\TVDelegate.cfc
\com\company\appname\TVFactory.cfc

So basically lets say the TVFactory contained instances of DAOFactory and AudioService (bad design example, but you’ll get the idea). Because they are not in the same path, you’d need to use full dot notation for their return types. I’ve done that before, but have had small problems with it here and there and ended-up having to change a bunch of code because of it. It’s easier to just do a return type of any, and also I think staticly typing everything is also getting away from one of the advantages of CF– loose typing.

I’m suprised that you didn’t dig the instance structure. It has really come in hand for me doing debugging, especially when your components deeply nested.

And lastly, could you do into a little more detail about how you find the returntype being any helps with components in different paths? I haven’t really gotten into lots of component subdirectories yet, but I imagine I will sooner or later.