> > There's a fair bit written about locking in CF. This is not > > specific to > > CFCs. There's no simple answer. You have to lock to avoid > > race conditions, > > but identifying and correcting race conditions is a bit of a > > black art. > > No animal sacrifice involved, I hope. 8) >
Only the usual chickens. > > BTW, cfproperty maybe doesn't do what you think it does? In > > object-speak > > "property" is a synonym for "instance variable". Unless > > you're creating > > webservices, cfproperty has nothing to do with instance variables. > > I just used cfproperty to make it clear that its type was > to be a CFC. Thought that might have been it - just checking. > > > > 5. If a CFC (FirstCfc) property is a reference to another object > > > (SecondCfcInstance), can SecondCfcInstance "see" the FirstCfc's > > > properties and methods? > > > > Public methods - yes. > > Package methods - if in the same directory. > > Private methods - no. > > Properties (i.e. instance variables) in the "variables" scope - no > > Properties (i.e. instance variables) in the "this" scope - yes > > Basically the same as any other piece of code? If I understand > you, SecondCfc doesn't gain anything by being referred to in FirstCfc; > only FirstCfc can now see SecondCfc's properties and methods? > That's right. Only FirstCFC and the garbage collector will ever know. > > I'd like to go off on a tangent here and recommend that (if > > you haven't > > already), you have a look at Subversion and CFCUnit. It > > sounds like you're > > going to want play around with a few different approaches, > > and if you set up > > version control and automated testing you will remove 90% of > > the stress in > > doing that (other than that next deadline...). > > Already 4 weeks late. Probably should have stuck with the > procedural approach for now, but I don't get time between > projects to learn new stuff, so I just dived in. Diving in is good. Who has time between projects? Next time you have a couple of hours, get CFCUnit or CFUnit and have a look. Next time after that, write a couple of tests for the next feature you're planning to develop. Then read Kent Beck's "Test Driven Development By Example". This is not complicated stuff but it might change your life. As for version control, if you don't have the time or mental breathing space to bite this off, get a consultant in to tell you what to do. It's pretty mechanical stuff. Actually, the reason I thought of this is when I looked at your outline of your CFC's, the first thing I thought was "Well, if it works, it's a good design". So how do you know if it works? And the second thing I thought was, let's say I comment on this and you make a change. How do you know if it *still* works? So I thought, well, let's not pick this apart, let's get the basics (version control and automated testing) in place. *Then* you can start playing with it. So I wasn't just ignoring your code, just focussing on some necessary preliminaries. All of that aside, you've still got your deadline, so by all means fire away with the tactical questions that will help you get this out the door. Jaime Metcher You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
