Thanks, Isaac. I appreciate your help in clarifying this for me. You were also absolutely right that I was missing the scopes part. I forgot that CF looks for unscoped/prefixed variables in numerous scopes. I'm obviously used java where there is only one scope (local) if something isn't prefixed. It's also been a while since I've messed with pointers to functions. So in CF someone can pass the function as the argument to the CFC (or in another scope that doesn't require a prefix), and the CFC can then invoke that argument - without prefixing the variable. I was forgetting this. I now understand why CF couldn't do what I was talking about. Thanks, Bob
>>> [EMAIL PROTECTED] 4/26/2005 6:43:12 PM >>> > This muddies the waters between the parent and its > children. It forces me to look at all the implementation > details of a parent class to verify that it doesn't > reference an undefined function that I'm expected to > implement in my subclass. It seems to completely break > encapsulation. If parents want to assume something about > their children they should be force to write an empty > method within the parent that children then > override/implement. This is how a lot of code I've seen > is written, and is likely a best practice, but when CF > can enforce this contract more explicitly with better > error messages to the developer why shouldn't it? > What is the reasoning behind allowing this? Am I missing > why allowing it is a good thing? Sorry if I'm repeating > a conversation that took place 2 years ago. I'm a little > behind. :) You might be repeating, I don't know... As to the issue specifically of CF allowing you to write functions in a CFC which aren't declared within the same CFC... remember that the rule of thumb with CFML is that it's designed intentionally to be lenient, so in general if it's possible for CF to not produce an error, it will <drum roll> not produce an error. :) CFML does provide some typecasting ability between cfparam, cfargument, variable-type checking functions and JavaCast() (which has a must more specific purpose), however, validating conditions generally needs to be done explicitly if its done at all in CFML. In the case of CFC methods specifically, you also need to consider that in addition to the language being generally lenient, CFML has for many years now included a hierarchy of contexts in which variables can be found (variables, form, url, and I think there are one or two other contexts) which are automatically checked when a variable is unscoped. Since functions in CFML are variables (pointers) and can be manipulated like other variables (stored in structures, etc.) the language doesn't know at compile time what the contextual environment will look like when the CFC is instantiated and used. So your CFC may call methoda() within one of its methods, and that function may be declared in the local scope of the executing (procedural) page. Java doesn't have these contexts (that I'm aware of) and so it makes sense that Java might require all called methods to exist in the class being created currently if not in a parent class or interface (which CF doesn't have), since the current class is the only context in which methods can be called unless another object is instantiated internally within the class. Whether or not this is a best practice is another question all-together -- the language merely allows for that or for methods to be injected into an instantiated CFC-object, etc. and allows individual programmers to decide what they feel is the best practice. Personally I don't see a real disadvantage to this. To this statement specifically: "It forces me to look at all the implementation details of a parent class to verify that it doesn't reference an undefined function that I'm expected to implement in my subclass." I've always been under the impression that it was the job of documentation to tell you what needs to be implemented, rather than relying on language details. Language details can easily be (and often are) badly implemented or otherwise misleading -- I don't see lacking this particular characteristic in the language as creating work... maybe encouraging that work that should be done anyway actually gets done. At the end of the day it's a bug, and the documentation can be just as wrong as the code, so one way or another imo you're fixing bugs. s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://www.sys-con.com/author/?id=4806 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:204729 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
