> > Done right, CF doesn't need to give up anything to provide
> > optional support for strong typing any more than they had to
> > sacrifice anything to give us CFCs.
>
> How do you know this?
> We can all speculate on how easy or difficult something would be, but
> I find
> it hard to reach this sort of conclusion without having access to the
> CF
> source code.
On Jul 9, 2004, at 5:54 AM, Dave Watts wrote:
> Done right, CF doesn't need to give up anything to provide
> optional support for strong typing any more than they had
to > sacrifice anything to give us CFCs.
How do you know this?
We can all speculate on how easy or difficult something
would be, but I find it hard to reach this sort of
conclusion without having access to the CF source code.
I am talking about WHAT: "optional support for strong
typing" can be added to CF in such a way that the advantages
of CF need not be sacrificed.
I didn't say HOW: if it would be easy, or difficult -- I
don't have the expertise or access to the information
necessary to make that conclusion -- so I did not make it.
That said, I can suggest a couple of ideas that might be
practical to implement:
1) implement *Optional* strong typing within CFCs where
typing is already partially implemented & enforced.
2) implement *Optional* strong typing within a block of code
-- similar to a cfsetting tag -- EnableStrongVariableTyping="yes".
3) implement *Optional* strong typing by having an option in
the script tag.
As I see it, this *option* when specified, would apply to
the enclosed block of code:
1) all variables defined within the block would need to be
declared and typed.
2) all external (untyped) variable references could be:
--- a) disallowed
--- b) require casting when referenced
--- c) made available & typed thru a mechanism like cfargument.
I have no idea how difficult or practical these would be.
I understand that there are differences between Java data
type and CF data types.
But, I believe that "Optional Typing done right" would pose
no burden on the beginning CFer (he wouldn't use it), and
would be of benefit to the advanced CF programmer.
The latter will likely be familiar with a strongly-typed
language, and already uses more advanced CF features: CFObject, CFCs,
cfscript, etc.
If the latter were a Java programmer, it is possible that he
could write portions of his CF code that would approach a
one-to-one correspondence with equivalent Java code.
Some benefits of this might be:
1) more efficient code generated by the CF parser -- less
need convert/validate data types in the generated Java/bytecode.
2) the programmer would have less need to abandon CF for
Java.
And, CF could be sold into a new, broader market -- as a
RADD Java front end. Explained, and demonstrated properly,
to experienced Java programmers/managers, this new CF is a
tool to address the "backlog". Rather than an incompatible
diversion, it represents a consistent and compatible step to
implementing the "total application workload" -- kind of a
"RaddJava" with its own bytecode compiler.
I think you can sell this concept to enterprises and Java
programmers alike, without resorting to the subterfuge that
Sean C. used.
Optional, strong typing would likely make this an easier
sell!
And that would benefit us all!
(IMO)
Dick
"Politics is the art of looking for trouble,
finding it whether it exists or not,
diagnosing it incorrectly, and
applying the wrong remedy."
-Ernest Benn -
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
