able to create strongly typed (your use of the word typed in #2 is not
correct) variables that map exactly to java instances of any java class. Of
course there are issues with passing these around and storing in different
scopes, so I would vote for having this available only for "var" scope
variables inside functions.
There are two reasons for this. First, if you decompile the genreated class
files in 6.1 (or even in 6.0) you'll see that CF jumps through a lot of code
to retrieve a variable from the scope, "auto-scalarize" it, and often cast
it using special cf-specific casting functions every time a variable is
referenced. All this would be removed if we could directly use java
variables. Second, all use of java variables in CF goes through the
reflection layer and is therefore significantly slower than corresponding
code written directly in Java or in a JSP. Direct access to Java variables
would remove the reflection requirement.
Case sensitivity (your #2) would not benefit the language in any way in my
opinion. Not sure about the collection availability--if we have java
variables, then we have java collections, so it's really a part of #1.
Sam
----------------------------------------------
Blog: http://www.rewindlife.com
Chart: http://www.blinex.com/products/charting
----------------------------------------------
-----Original Message-----
From: Joe Eugene [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 29, 2004 9:41 AM
To: CF-Talk
Subject: Re: How does CF generated Java bytecode compare with Native Java
bytecode
I believe there are areas where CFMX CFML could improve to be closer to
Java.
1. "Optional" Primitive Data Types (int, long, String, boolen etc)
2. "Optional" Strongly typed language (int a != int A)
3. Improve the Collection Framework Availability.
I think the above "Optional" features when turned on would help translate
CFMX CFML
closer to Java Contructs.
Joe Eugene
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
