typecasting in components

62 views
Skip to first unread message

Mikaël Spruyt

unread,
Feb 17, 2015, 9:11:35 AM2/17/15
to lu...@googlegroups.com
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:

<cfcomponent output="false">
    <cfproperty name="thisId" type="String" default="-1" />
    <cfproperty name="thatId" type="String" default="-1" />
</cfcomponent>

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

Michael Offner

unread,
Feb 17, 2015, 9:50:40 AM2/17/15
to lu...@googlegroups.com
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
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f54c9fae-bd42-4712-85e5-64fd76cee15b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mikaël Spruyt

unread,
Feb 17, 2015, 10:05:53 AM2/17/15
to lu...@googlegroups.com
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ël
Micha
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.

Nando Breiter

unread,
Feb 17, 2015, 10:16:45 AM2/17/15
to lu...@googlegroups.com

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.


I've recently seen a similar issue where I had intentionally cast a query column as a string (varchar), but Railo (and I assume now Lucee) would automatically type any value it could to a numeric. Some of the values in this column could not be converted to a numeric, so that suggested to me typing was not being set on the column as a whole but on individual values, or something along those lines.

What I needed was that values such as 43.3, 43.30, and 43.300 (think of these as part or catalog numbers) would be treated as unique strings, but Railo ignored the type of the column, and converted, when it could, these values to numerics, and then catalog numbers 43.3, 43.30, and 43.300 were treated as equivalent, which meant the app could no longer find the catalog entry by catalog number. I worked around it to get the app functioning on Railo.

I have it on my ToDo list to develop a test case and file a bug report for this ... 



Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia
Reply all
Reply to author
Forward
0 new messages