But what is the alternative?
Running multiple versions of CF?
if MM or NA wants to move the CF install base to their latest versions,
then providing total backward compatibility will forever restrict the
implementation to the mistakes and limitations of past versions.
MM did not do this (entirely) when they introduced CFMX -- they
provided a sift program that pointed out discrepancies between CFMX &
prior versions.
There are advantages and disadvantages -- the code was brought up to
date -- but you had to recode and test before migrating an application.
My main point is that the compatibility issue needs to be addressed!
Many people defined and built the computer infrastructure that brought
us to this point. Circa 1959, Admiral, Grace Hopper, in her wisdom,
was able to offer the US Govt. and all it's subcontractors stability
and expandability with CoBOL -- certainly there are people smart enough
to do it with CFML.
I wrote programs on the IBM 1401 (1961) IBM 1410. IBM 360, IBM 370
(1980). With few exceptions, each program had to be recoded to run on
(or take advantage of) the new machine. A major exception was programs
written in CoBOL (and to a lesser degree ForTran). Each release of
these languages included Compiler directives that defined to what
version of the language the program was to be compiled.
Sure, it wasn't the most efficient, but Software and Hardware vendors
could move their installed base to the latest "whatever" with minimal
(the key word is minimal) effort.
Compatibility did not get in the way of progress!
This was the best of both worlds -- legacy programs ran (and could be
maintained) on the new system while new programs could exploit the
latest features of software and hardware.
Dick
On Aug 8, 2004, at 5:08 AM, S. Isaac Dealey wrote:
> I have to agree with Dave...
>
> Beside requiring changes to existing code, many of the tags in CFML
> are implemented as regular CFML custom tags -- they're in one of the
> directories in your cfmx installation, although I don't remember which
> offhand. Which means implementing the <cfsetting version="5.0"> tag
> would require modifications to both languages, and some way to
> communicate to the cfml pages via likely a cgi variable what version
> is currently being processed... Nevermind that providing this
> functionality would over the course of time create rather bloated,
> spaghettied, inefficient code within the server's core components,
> It'd drive me mad to have to constantly be informing other developers
> who hadn't become aware of the tag that their code may not be working
> because of a <cfsetting> tag anywhere in their request and that they
> need to check a cgi variable to determine what version is currently in
> use in their request. You'd end up seeing all kinds of custom tags
> where the version is set at the beginning (and hopefully end) of the
> tag, so the server would constantly be switching back and forth
> between versions during any given request, potentially soaking up lots
> of extra cycles in the process. And heaven forbid you get a bunch of
> custom tags from someone with "enough knowledge to be dangerous" and
> they set the version at the beginning of the tag but not at the end or
> they set it in both places and then cfexit the tag in the middle
> without resetting it first. From a support and maintenance standpoint
> -- really from any angle I can think of to look at it, this is a
> logistical nightmare.
>
> > Aw c'mon Dave -- be reasonable, application.cfm &
> > onRequestEnd.cf,
>
> > Even I can understand that.
>
> > Dick
>
> > On Aug 7, 2004, at 7:29 PM, Dave Watts wrote:
>
> >> > To me, backward compatibility means a new version runs
> >> > prior version
> >>��> code just like the prior version -- not that the new
> >>��> version
> >> additions
> >>��> will run on a prior version.
> >>��>
> >>��> I meant that new version of CF could accept prior
> >>��> version syntax,
> >>��> assumptions. etc, by enclosing the target code within
> >>��> tags that
> >>��> specified that the compiler should treat the enclosed
> >>��> code as the
> >>��> indicated prior version.
> >>
> >>��But that would require that you change the code - having
> >>��to enclose
> >> the
> >>��target code would be a change to that code.
> >>
> >>��Dave Watts, CTO, Fig Leaf Software
> >>��http://www.figleaf.com/
> >>��phone: 202-797-5496
> >>��fax: 202-797-5444
>
> s. isaac dealey�����954.927.5117
> new epoch : isn't it time for a change?
>
> add features without fixtures with
> the onTap open source framework
>
> http://www.sys-con.com/story/?storyid=44477&DE=1
> http://www.sys-con.com/story/?storyid=45569&DE=1
> http://www.fusiontap.com
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
