If you define a CFC argument as being required="false", and then do not pass it in, it will, of course, return false if you do isDefined("foo") or isDefined("arguments.foo"). However, if you cfdump the arguments scope, you can clearly see foo (or whatever the name of your argument was) in the structure. The value is "[undefined struct value]", which to mean smells like null, but CF has no real support null.
Archived Comments
Yup, weird isn''t it? I mentioned it here (http://www.corfield.org/blo... and noted that arrayLen(arguments) in particular can be misleading...
Ack - didn''t mean to repeat anyone. :) (I _do_ read your blog.) It just goes to show that we <i>really</i> need a firmer grasp of null. It would be even better if foo simply didn''t show up in the structure at all.
Also - it seems like the effort that was put into the arguments thing to make it support both array and structure type notation kind of left things messy. I would have preferred just struct or just array type notation.
You can, though, do a test for null by comparing the value to chr(0) -- in the case of an "empty" argument it will equal null in that test.
It is very strange to have structKeyExists() return false but still be able to output that key from the struct (though, strictly speaking ARGUMENTS is not a "normal" CF struct).
That''s why I say again - I wish MACR would have made the arguments thing a bit simpler. I understand why they wanted it like an array since UDFs in CF5 treated arguments as an array - and I understand how we need names as well, since it makes it easier code wise and it''s how arguments were addressed in CF5 UDFs as well. However, I just think this could have been done in a simpler way - somehow. To be honest, I don''t know the answer, so I don''t blame MACR for not getting it perfect either. (And to be honest, this is being kind of picky. :)