Extensibility does not replace the need for new functionality

S.Isaac Dealey posted an interesting blog entry about whether or not certain functionality should be added to the core CFML language. He was talking specifically about the ability to work with zip compressed archives but the argument applies to many other things.

His assertion is that since a lot of functionality can be easily added through the use of ColdFusion extensibility options–User Defined Functions, Custom Tags, and ColdFusion Components–and because of this some common functionality does not need to be added to the core CFML language or function library.

I completely agree that developers should take full advantage of extensibility and the great resources available to us such as cflib.org and Macromedia Exchange. With these options individuals can add functionality to CF and share that functionality with others.

However, I disagree that this replaces the need for new functionality to be added to the core language for several reasons.

Availability. Having functionality included in the language natively means that a developer can use it immediately and doesn’t have to locate an external UDF/tag/CFC. It also means that the functionality is available globally to the whole server without having to include it or use some code that may be server specific to initialize the extensions.

Quality. Functionality included in ColdFusion has a certain guarantee of quality. While CF has had a few very buggy releases, overall the quality is high and the writing, testing, and version control standards are higher than is present in most free libraries. I know from experience that cflib.org does very good testing of UDF’s submitted to them, but that is not the case in all libraries and initial testing doesn’t compare to a full battery of regression tests.

Speed. Particularly when wrapping Java calls in CFML, speed can become an issue. For cases such as the zip functions under discussion, the code interacts with several Java objects in a potentially long loop. Whenever CFML code makes a call to a Java object this call is always made through reflection. What would be a simple object call in Java translates to several levels of object calls in the code generated by ColdFusion and utilized by the underlying CF runtime libraries.

For these reasons, I would hope that in the next version of ColdFusion, the engineers would in fact take a look at the whole J2SE and J2EE libraries and add some new native CF functions or tags that wrap available functionality.

9 thoughts on “Extensibility does not replace the need for new functionality”

Oh I don’t disagree (nice article by the way). I was merely thinking that given Macromedia having limited resources, if I had to priorotize my desires for new core functionality in the server, I’d rather see them implement features that I can’t readily implement myself first, and worry about things like zip later (and JavaScript MUCH later). Plus it’s nice to know how far we can push that extensibility envelope, like this recent entry: http://www.turnkey.to/ontap/blog/?20040124 Beyond the wrapper tag for cfstoredproc I frequently create wrappers or replacements for native tags and functions to either add features or produce a consistent method of resolving issues I’ve had with some of the native features.

As an asside, related to availability there’s also the advantage of consistency in development, which can be a big help to those of us who do a lot of consulting work. Since core functionality is more frequently adopted, it reduces the need for us to learn and/or catalog multiple third-party tools for the same purpose. The fact that there have been a couple different wrapper tags for cfmail springs to mind (although it also demonstrates that the native features aren’t always a cure). I wrote one myself that degrades gracefully between CF5 and CFMX. DHTML menus also springs to mind, although I’m not convinced I want to see MM working on that.

One thing I’ve found when working on commerical products is that it often is nice to spend a whole day on small low-priority items. The result is you can get a lot of mentionable items done even if it wasn’t really all that much work. I see adding native CF functions that wrap J2SE/J2EE functionality in the same boat.

Blackstone can come out with lots of new functions and native support for different technologies without it really taking a lot of development time.

It does add to QA and support, so there is still a trade-off.

That’s the second reference to “Blackstone” I’ve seen in the past 2 days, and I have to admit my ignorance. Though the description does bear a striking resemblance to my experiences with the onTap framework. When I have time I frequently add new features of one kind or another on a daily basis. Most of them not significant enough changes to the core architecture to announce even a new minor version, so I just increment the build number.