>> Sooner or later, backwards compatibility inhibits
>> progress.
>> Macromedia will need to address the BC issue or others
>> will

> Unfortunately, we all have different definitions of
> progress. Most of the
> things that people have mentioned in this thread - NULL
> values, strong
> typing, etc - are things that go quite a bit against the
> grain of what CF
> does best. If you want to do these things, there are
> plenty of languages
> that do them already. Enough of that sort of "progress",
> and you might as
> well just write Java.

With a number of them I agree ... strong typing as a good example of
something I think CF is better off not having. Nulls are an exception
for me. I don't perceive nulls as being a complex enough concept that
they would overly complicate CF development -- for that matter, I
think the concept of null is significantly simpler than most if not
all of the concepts introduced by CFC's. Yet the lack of a null in CF
is one of the most common areas where I have to create complicated
end-runs around the situation to make up for the fact that I can't
just declare null. So as opposed to being something complex that's
left out to keep the language simple, imo nulls are something simple
that keeps the language from being as simple or as easy to use as it
could be as a result of being left out.

> I suspect things wouldn't be that simple
> - there are quite a few tags that, for
> internal reasons, can't be started in one
> file and finished in another.

Anything with an end-tag... cftry, cfswitch, cflock, etc, etc...

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]

Reply via email to