Hi Roland, But how do you fully describe all of the possible errors and the difference between warnings and fatal errors (if it is a warning you might not want to cfthrow)? Of course, you can put any information in a hint, but it doesn't mean that people will do it consistently or comprehensively.
Have you ever been able to write an entire real world application where none of the objects have a single pre or post condition? No matter what I put into any of the fields, as long as it meets the data type it will be handled appropriately? Most applications in practice don't exhibit that level of encapsulation. How do you use strong typing to distinguish a date (passed as a string) from a name (passed as a string)? How do you use strong typing to enforce the validation that the passed int must be between 3 and 47, or not more than 2 bigger than another field? Of course you can run those validations within the component, but how does the component describe those restrictions as part of its interface? I personally still pass structs in certain circumstances as they can be more performant than objects - especially when dealing with large collections (I know I could create an object pool, but that's unnecessary complexity in certain situations) - and because I never reuse code (just regenerate it) I can make different design decisions than I would if the code were a primary artifact. I could go on and on, but the point I am making is that just knowing the method list and the arguments, argument data types and return type for a class is not sufficiently descriptive for reuse (I would say it is arguably necessary but clearly not sufficient in all cases). The rest still needs informal commenting and informal commenting written by human beings often leaves out special cases, exceptions, or other information you might potentially need to know. Best Wishes, Peter SystemsForge -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roland Collins Sent: Thursday, April 06, 2006 4:40 PM To: [email protected] Subject: SPAM-LOW: Re: [CFCDev] Mixins vs. Interfaces -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell >The fact is that components only take you so far for reuse anyway. Even >if you use strong typing and interfaces, components don't specify how >errors are handled, they don't explicitly document preconditions and >postconditions, they don't explain the structure or semantic meaning of >data passed (great - I have a struct - but what does each of the keys >mean?!). Errors should be thrown via cfthrow. That, or the hint field can be used to explain returned exceptional values, but for my money, throwing errors that can't be handled by the component internally is the best practice. Objects should not have pre and post-conditions for operation. If they do, they're not properly (or fully, anyway) encapsulated. If you were using strong typing, you would no longer pass structs - you would create objects with member definitions to handle the data elements. Roland ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
