> correct)
I am not sure what you mean "#2 is not correct". "int a=1" and int A=2" are
NOT the same in Java.
Oh..i should have said "Case Sensitive"
http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/Java5.htm#1160838
I am not sure of the validity of the above documentation. Java String[] ==
CFMX Array == Vector.
If you do the above and try to manipulate the contents of the String[] as a
Vector --> Fails.
"var scope" is good idea, how about some of the CFMX variables that are
forced
"Pass by Value" instead of "Pass by Reference"? I think that could be solved
by bringing CFMX
closer to Java Architecture.
> files in 6.1 (or even in 6.0) you'll see that CF jumps through a lot of
code
Very True
> Case sensitivity (your #2) would not benefit the language
I am not sure of the internal workings of Java on this, but i do believe
there is a reason
why Java is Case Sensitive.
Joe
----- Original Message -----
From: "Samuel Neff" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Tuesday, June 29, 2004 10:32 AM
Subject: RE: How does CF generated Java bytecode compare with Native Java
bytecode
> I totally agree on #1 but not limit to primitives. I believe you should
be
> 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]
