> My impression from some of the people on the CF Development team is
> that
> this would be a nightmare to develop while maintaining backwards
> compatibility.��Making the whole language typed, period, would be
> somewhat
> easier - but only in a sense, as you would really just be ripping out
> the
> massive amounts of code that handle typelessness - a huge job by
> anybody's
> measure.
>
I was going to suggest a special scope for typed variables, but I
thought it might be too kludgey.
Untyped or current types would remain what they currently are --
untyped.
But referencing vars with something like typed.name,
typed.employeeNumber would be clumsy & prolly turn off Java
programmers.
Or, maybe it wouldn't be -- if the "typed" scope were logically handled
like an external class file.
1) all typed variables could be referenced w or w/o the "typed" scope
2) in a block of strongly-typed code the "typed" scope would implied
(roughly analogous to Java's import statement)
3) Then The CF parser/compiler would have a set of readily-identifiable
strongly-typed variables, that it could resolve efficiently.
Don't know if this is possible, practical or just plain dumb.
> However I did have one idea that might be able to address this
> somewhat - at
> least partially.��Of course it could also be the stupidest thing ever
> thunk.
>
> What if you could apply type validation on a per-variable
> basis?��Basically
> assign a type to a variable and have every write to that variable
> tested for
> that type.
>
> The language implementation would be tricky.��I would propose, off
> the top
> of my head, that CFPARAM could have an attribute added:
>
> <cfparam name="Foo" type="boolean" enforceType=true>
>
> The "enforceType" parameter would be optional and default to "false"
> to
> ensure backwards compatibility (I would add the same attribute to
> "cfargument" as well).��The setVariable() function could also have a
> third,
> optional parameter added to enforce type (again defaulting to
> "false"):
>
> #SetVariable(Foo, Value, true)#
>
> The hardest one would be CFSET since it doesn't follow a more
> traditional
> format (both the left and right side of the equals are dynamic).��You
> could
> do something like this:
>
> <cfset foo = value enforceType = true>
>
> That's really just two attributes to the tag.��However personally
> would
> probably rather see a new tag.��Perhaps something like this:
>
> <cfset foo = value >
>
> <cfsetType foo = "Boolean">
>
> And perhaps a corresponding function:
>
> #SetVariableType(Foo, "Boolean")#
Or, how about:
<cfset boolean Foo = true />
boolean Foo = true;
and
boolean Foo = (boolean)("yes");
>
> I would personally only want to see simple typing using this: Boolean,
> Numeric, String, Date, query, struct, CFC Names, etc - not
> int,long,float,etc.
>
> In practice this would mean that the whenever the variable was
> written to
> AND it had a defined type then that type would be checked.��However no
> checks would be done on reads.
>
> Just the write checking would most likely incur a (small) performance
> hit
> but since you would presumably only be using it for "important"
> variables
> then it's something you'd be able to manage.
>
> As an aside I'm not convinced CF needs typing at all - but I do love
> automatic type validation so you could say I'm on the fence.
>
Some pretty good ideas, though!
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]
