> > For example, if converting code from typed to untyped for performance > reasons,
Anyone know of an article that explains this (I'm blissfully unaware of this issue)... I like your thinking. I once wrote a CFC Documentor, for inhouse use, that documents the component in either HTML or Word XML so that we have static documentation to hand to the client. It used the metadata and I toyed with adding custom properties but thought it would only confuse things. A matter of getting a standard together I suppose... Dom On 11/07/07, Jaime Metcher <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > > From: Tom Chiverton [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, 10 July 2007 7:16 PM > > To: CF-Talk > > Subject: Re: SURVEY RESULTS: Is ColdFusion OO? > > > > > > On Tuesday 10 Jul 2007, Sean Corfield wrote: > > > In ColdFusion, all type checking is done at run time. So if you use > > > interfaces, you will get a *runtime* check, just like all the other > > > checks. And if you screw up, you'll get a runtime error. If you use > > > interfaces, the error just has different text in it (OK, that's a > > > *slight* oversimplification :) > > > > I want Interfaces so I can aid other developers intergrating with > > my code- it > > explictly codes the contract. > > > > I love the idea of documenting the intention - something that can be very > obscure using mixins. However, as Sean and Ben Nadel have pointed out, > there is no enforceable contract, so cfinterface turns into an elaborate > commenting mechanism with a runtime performance penalty. That reminds me > of > another idea for documenting intention in a structured way that *doesn't* > have a performance penalty. > > I'm certainly not the first person to point this out, but you can add > arbitrary attributes to the cfcomponent, cffunction and cfargument tags > that > then appear in the metadata. I'd love to see the community generate some > momentum on a standard set of metadata to aid in code introspection. > > For example, if converting code from typed to untyped for performance > reasons, instead of removing "type" and "returntype" attributes, why not > change them to "_type" and "_returntype", thus documenting the original > intention?. If ducktyping, the _type attribute could read "any CFC that > implements getID()" for example. It would then be simple matter to adapt > CF's builtin CFC introspection to read these attributes. > > Similarly, if you have a function in a superclass like this: > > <cffunction name="doSomething"> > <cfthrow "Subclass responsibility"> > </cffunction> > > why not add an "abstract" attribute to document the intention. From there > it's not too hard to parse the metadata into XMI and produce a UML > diagram, > if that's what floats your boat. And I know there's somebody out there > (sorry -forgot who you are) who uses cfproperty tags to document > composition > relationships. > > This *is* just documentation, *not* an attempt to add Java-style > annotations, and isn't necessarily any more accurate than any other > documentation. The cool thing is the ability to import it into other > tools. > > Jaime Metcher > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion MX7 and Flex 2 Build sales & marketing dashboard RIAâs for your business. Upgrade now http://www.adobe.com/products/coldfusion/flex2?sdid=RVJT Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:283444 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
