> new features -- not to use these when needed, is a failure to exploit
> the tool.
That doesn't really have anything to do with backward compatibility.
BC is so that code from previous versions runs unchanged (or very
nearly unchanged) on newer versions. That means that adding new
features must be done in a way that doesn't break existing features.
> 1) Don't you get overloading capability with the JavaCast() function --
> at least when you drop into Java.
That's a hack to let you call overloaded methods in Java.
> 2) When coding with <cfscript>, say some CFCs and using some CFObjects
> -- the code begins to strongly resemble Java source
Not really. It's more like ECMAScript than Java really.
> Aside: When can we expect CF language support for ="" !=, <=, >= ?
Adding <= and >= would cause some parsing problems since < and > are
tag delimiters. Look at Flex and what it requires to be able to embed
ActionScript:
<![CDATA[ script goes here ]]>
> 3) My gut tells me that there is a need for a middle ground between a
> procedural language like CFML and an OOP language like Java.
Currently CFMX is in that middle ground. Python and Ruby are probably
also in that middle ground.
> 4) A recent article suggested that CF was a way to rapidly get a (web)
> application running, until it could be programmed "Right" in Java. IMO,
> this is folly -- there will always be more pressure to implement new
> apps, than to expend the resource to recode existing apps).
Agreed. If it works fine in CF, why bother recoding it? Performance,
possibly, but when I say "works fine" I mean that it is fast enough
(as well as functional enough). I admit that I've used that argument
(prototype in CF, recode in Java) to persuade pro-Java folks to do a
project in CF, knowing that there would never be time / resources to
rewrite it in Java later.
> 5) Aren't the people developing/using machii, in reality, trying
> reforge the use of CF (and other languages) into something more like
> Java
Not really. Mach II is designed around what CFMX provides today - in
fact Mach II's development was held up until 6.1 was available, so
tightly coupled to CFMX was it. Mach II exists for PHP as well,
leveraging the OO features of PHP4 and only requiring one additional
piece of 'machinery' in order to work the same way as the CFMX version
does. If anything, CFMX has shaped and driven Mach II.
> 6) Wouldn't it be beneficial to everyone, MACR & NA included, If the CF
> Language were extended to be more "Java-like"? This is rhetorical,
> because, in fact, this has already occurred with the aforementioned
> CFCs.
Well, I don't agree at all. I don't agree that blurring the
distinction between CF and Java would benefit anyone. The more
Java-like it becomes, the more people will say "Oh, just program in
Java". CF needed some OO features for a variety of reasons but CF
doesn't need to be similar to Java. In fact the whole "this" issue
draws more on ActionScript / _javascript_ as I understand it - it
certainly isn't Java-like.
> But here's
> an interesting question: Would I be better served, trying to bend my
> CF code to be more Java-like; or to write procedural code in Java and
> (mostly) ignore its OOP capabilities?
Neither. You should take advantage of Java's rich OO support to learn
a broad spectrum of OO techniques. You can then take advantage of
those OO techniques for the most part in your CF code if you want to -
not making your CF code "more Java-like" but using the bigger OO
picture to write better structured CF code. That means being able to
understand and take advantage of things like Design Patterns (which
are almost all language-agnostic).
> > IsNull() would be pretty handy, though! Ben F....anyone else from
> > MACR reading....can get this on the list? :)
>
> You also need: <cfset x = NULLl />
Or <cfset x = createNull() />
Various requests for both of these functions - and other required
semantic knock-on effects - are already in the Macromedia bugbase...
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
