Bob, After reading thru these code snippets and your summary, I think what you're asking is "Why can I implement functionc in sampleb when samplea doesn't implement functionc at all, but does call it?"
Is that right? Short answers: CFMX's OO features are relatively new. Give it time, maybe it'll "improve." Because CFMX is not Java. Because CFMX is not C++. Because CFMX is CFMX, and as such any implementations you do in CFMX must be done as though you were implementing in CFMX. First of all, a good number of folks have, as you say, implemented blind methods that simply throw an error in a base class, which naturally requires an overridden method wherever it's used in the implementation classes. So it can be done, even if it's not handled directly by the CFMX engine. Second, never having written more than about 200 lines of Java, and probably less than 50 altogether in C++, I may be not "getting it" when it comes to understanding why limiting things, especially when they're not "broken" but simply different than Java would actually be an improvement. There are rules... you just have to know what they are. It would be kinda handy sometimes to have interfaces, multiple inheritance, and/or "real" constructors... but, as you said in an earlier post, Java is a beast... so why would we want to take an awesome, loosely-typed implementation of something like the BCEL and turn it back into "the beast"? Its rules *are* loose, as is datatyping, and they're this way because CFMX isn't Java, it's a J2EE application that runs on a JRE. Why invent what would amount to a new syntax for Java when we could just keep using Java for writing Java and approach CFMX as something entirely different? Something to think about... Laterz, J On 4/26/05, Bob Jacoby <[EMAIL PROTECTED]> wrote: > You're absolutely right. It was my misunderstanding of a book I read > describing the functionality in CF. However, rather than test it through > a simple test case because it sounded weird to me, I accepted it. I was > wrong. I was actually wrong in more ways than one... My interpretation > of what the book was saying was wrong. It has nothing to do with calling > an overridden method in a child class - it's about calling functions in > the child from the parent even if the function isn't defined in the > parent. I've since discovered (through testing that "this" isn't > required at all). This new understanding makes me go "huh" so I'd > appreciate input... <snipped> -- --------------- ------------------------------------- Buy SQLSurveyor! http://www.web-relevant.com/sqlsurveyor Never make your developers open Enterprise Manager again. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:204610 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
