Well you're really describing a perfect use for Interfaces if you're talking about that type of reusability. Other languages do provide great constructs for dealing with all of the problems that you describe. Java allows you to define the types of exceptions that can be thrown, for instance. .NET allows you to include all *sorts* of cool metadata stuff with your objects to describe components in what sounds like much the same way you may be - a large part of that actually using interfaces and tagging.
What it sounds like is that you've arrived at "Interfaces by Convention", which is pretty much what a loosely-typed language like CF forces you to do, and it isn't necessarily a bad thing, just a different approach. Personally, I prefer "Interfaces by Contract", which is why I *really* hope CF implements Interfaces soon. Anyway, back to the original reason for this thread.... :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell Sent: Thursday, April 06, 2006 6:05 PM To: [email protected] Subject: RE: SPAM-LOW: RE: SPAM-LOW: Re: [CFCDev] Mixins vs. Interfaces Hi Roland, Appreciate all the ideas, guess we're looking at this from two different perspectives summed up in your last sentence: > I don't know of ANY API that is usable without proper documentation. We're looking for machine level reusability - without any human intervention, so our approach HAS to work without documentation that requires human processing, common sense, judgement or anything else. We build our components with a bunch of conventions (as we don't need other people to be able to reuse the functionality - only us) and extremely detailed meta-data including sophisticated explicit dependency handling so that we can re-implement customized versions of components by checking a couple of boxes on a build form. In our experience it is absolutely possible to describe components in a way that our generator can automatically reuse them in different sites without a human programmer. You do however have to increase the richness of your interface description language to formally capture the details usually passed informally to programmers through free text documentation. (We also have various "intent" documentation fields to allow architects - who replace programmers - to determine what the intent of various items are and whether they are appropriate to reuse in a given project). I am convinced from substantial personal experience that even well written classes are not sufficiently descriptive for them to be automatically reused without human intervention, but that it is possible to develop a sufficiently descriptive interface language to cover the MAJORITY of situations. That's what we do! Best Wishes, Peter SystemsForge -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roland Collins Sent: Thursday, April 06, 2006 5:22 PM To: [email protected] Subject: SPAM-LOW: RE: SPAM-LOW: Re: [CFCDev] Mixins vs. Interfaces -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell >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. Warnings are really a business rule, not an exceptional condition. You could log them, ignore them - that's up to you when you're developing your business logic. I would never advocate using warnings for code flow. IMO, they promote "On Error Resume Next" style programming. If a condition is exceptional that means that it's a non-recoverable programming error and it requires that program execution stop and error handling code take over. I think a lot of people abuse the cfthrow/exception mechanism for things that really should be handled as business logic. >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. Absolutely - almost every single one of them! If objects are encapsulated properly, then it's extremely easy to do. If you need configuration information, you define your component to require a configuration object during initialization. Internally in all of your methods, you need to have some form of type checking to ensure that all values passed in are valid. If those criteria are not met, then it's an exceptional condition, and you throw an appropriate error. Configuration is not a pre condition - it should be an obvious point of interface for using any given object. >How do you use strong typing to distinguish a date (passed as a string) >from a name (passed as a string)? In a strongly-typed language, you almost always have a Date data type or class. However, if for some reason, you need to design your object to take in dates as strings, you ALWAYS perform validation before your object does anything. IsValidDate. >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? Those are business rules. If the data passed in is invalid, you raise an exception or optionally correct the data. Again, it's up to you to design the logic around that. >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. Then you should always be validating that the struct that is passed in conforms to the proper specification. This is a data validation issue, not a strong-typing issue in this case. >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. EVERY API should have documentation. However, *reusability* from the standpoint of encapsulation and *usability* from the standpoint of an API are two different topics entirely. If you properly encapsulate objects and minimize dependencies, then reusability should be a no-brainer. I don't know of ANY API that is usable without proper documentation. :) 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] ---------------------------------------------------------- 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]
