If there is no type conversion in Railo/Lucee, only a validation of the
type-casting possibility, what is then the purpose of the type argument of
a property?
I would expect that, if a component’s property has an available space for a
string (which is definitely not a number), the setter would either return
an error or cast the value to a string, when trying to set a value that is
not a string. Otherwise there would be, in my opinion, be no use to the
type argument of properties.
It’s all fun and games being able to set a number value to a string
property, until you expect it to actually be a string afterwards, like you
set it up to be…
I have only tested this in regards to setting a number value to a string
property, so I have no idea what actually happens when trying to input
other values into other types of properties here. But I could expect that:
boolean → string = boolean
number → boolean = number (if it is 0 or 1)
string → boolean = string (if it is “true” or “false”)
string → number = error
boolean → number = ?
Or am I assuming too much right now?
Is there a list somewhere with type-validation / what happens to when
setting…?
Is there a way to still enforce the original typing of properties?
best regards,
MikaëlOn Tuesday, February 17, 2015 at 3:50:40 PM UTC+1, Micha wrote:
When you define a type with properties or function arguments, cfml does
not convert your value to this type, it only checks if the type can be
castes to this type, take this simple example.
function test(string str) {
Dump(str);
}
test(123);
When you execute, you will see that 123 is still a number. Luce only
checks if the string can be a number, nothing else.
But there is s difference between acf and Lucee, acf translates all simple
literally to strings, take this example:
b=true;
n=123;
In acf b and n containing a string, in lucee they remain what they are.
Micha
Am Dienstag, 17. Februar 2015 schrieb Mikaël Spruyt :
Hi,
I’m experiencing some weird typecasting issues here, not specific to
Lucee (also in Railo). Could be that I’m just missing some crucial point
here though…
I have a component:
Both properties are clearly typed as strings. I would expect that when I
try to set an object or a number to one of these, the code would return an
error.
But, seeing as I’m used to cfml doing the typecasting for me by now, I
never thought twice about the fact that setting a number here is no problem
at all. I was in fact under the assumption that all number I would try to
set here would be cast to strings for me.
It seems this is not the case though.
After implementing some REST calls that contain derivatives of these
components in the form of a serialized struct, I onticed that some where
included as an integer and some were included as a string. When I noticed
that, I dumped out the component itself and notice that setting a number
where a string was expected as a property, the typing had been overwritten
as a number.
Seeing as I don’t want to be typecasting every number to a string right
now, is there a simple oversight here that could salvage my typing?
best regards,
Mikaël
–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f54c9fae-bd42-4712-85e5-64fd76cee15b%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f54c9fae-bd42-4712-85e5-64fd76cee15b%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.