Adam Cameron wrote:
SERIOUSLY... when are you going to have avariable "x", and *not* *know* what data type it is? To me that's a case of "get your logic sorted out. Not "I need a function to cater for that".
Like i said, *typically you should know*....but...one example comes to mind and that is interrogating clusters of dynamic variables, to determine if its to be traversed further (ie heirachy of struct/arrays/strings etc)...
In some cases Observer Patterns can do this, especially when doing dynamic audits on users movements between contexts and keeping localised dumps on "scoped" variables that are flagged as "varsToWatch" to determine a users overall movements/interaction with an API (ie a passive parasite object who carries out logging/other on certain key filters.
And, Sometimes it cannot be the case, especially if you are leveraging off someone elses API who persist in using returntype="any" or not at all. That can be fun.. and while purists within may *gasp* and cry, its simply the fun that is CFMX and why its so loose and return types can be any... (yes - you could re-write it, but faaaark, that can be another discussion onto itself - topic: How someone elses legacy crap and screw your time/money)
As for Ultimate *real* world uses for IsEmpty, In truth, you typically can find such things with
Form Variables for one? ie IsEmpty(form.var) ignore..don't save, nothings changed etc.
In Thinking about it more since last night, IsEmpty could really be IsStringEmpty() which may suite more to the purpose/point. I just casually mentioned that if a method called IsEmpty() were to exist, it could extend into Array, Struct & Strings..
But, I've seen and done the typical if the len(string) routines being used a lot through-out the code, and it would be a great concept to have a String based IsEmpty aswell, especially for CFMX'ers out there who ALSO like to use IF STRING IS " " THEN.... hopefully if a method were to exist, it could remove practices like this...
Before you reply with "yeah but thats just bad coding..." - yes it is on another level, but CFMX isn't restrictive enough to have someone turn around and lecture on "bad practices". If you want stricter practices in place, tighten the language no? otherwise developers can / will continue to do certain things that to most who *get it* dislike..ie IF STRING IS " " for one... god i've seen that so many times!
typically you have to do a bunch of procedures (as you've outlined) to
I don't think Steve was suggesting it's a set of evaluations that typically have to be performed as a group, and on a regular basis. More that there are already the individual mechanisms to evaluatethe emptiness of various data types.
Like i said, if such a method were to exist, you wouldn't necessarily need to have ArrayIsEmpty(), StructIsEmpty() and could argue that a consolidated method IsEmpty() maybe suffice? resulting in removal of such mechanisms if the case is that grouped "clusters" of unknown variables need interrogate...
an example of a dynamically changing variable composition is CFCATCH one instance it can be a straight forward struct, other times it can be an object unto itself.
and when using such vars within components declaring them via the "var" scope, has to be done upfront before you play with them.
You've lost me.
Well as you know, in a method all variables you intend to use within that method and are local, need to be declared first before you perform any logic, resulting in most cases a situation like
function
var i = 0;
var myVar = "";
var myTest = "";etc..
Now, it maybe in some cases deep down inside that method before an actual value is inserted into such local scope. If however that variable has not been populated as intended (eg: query column/row came back blank what not - use your imagination), rather then doing isDefined('myvar') (which will come back as true, unless you want that var then to be in the variables scope itself. in which case false...) you have to then do a Len(myVar) procedure.. once again.. IsEmpty (or *sigh* StructIsEmpty,ArrayIsEmpty etc)...
This is cool, but in some cases (being the current one),
Which one is that?
Now, typically *you* should know what variable being tinkered with is, and adjust to suite its "type" specifically..but, I've got a procedure which interrogates 'instance.scopesToWatch' variable (which is "url,form,request") etc..
OK, fair enough. But the way you've coded it, you've got to second guess whether any given key of each of those structs is a string / numeric / struct / query / etc?
What's an example of how you'd handle - for example - request.marmoset differently, should it be *not* empty, and is maybe a struct or a string or a query? It's all well and good testing for isEmpty(), but I would expect there to be a potential for that evaluation to be false, and you've actually got to do something with that information.
The first step is to determine if it is empty & not an object, regardless of its actual other possible types. If it is empty, ignore it go onto the next scope, removing further type inspection procedures.
If it is not empty, thats when a sub-routine can be carried out (ie IsEmpty or IsObject? No..isSimpleValue..No, IsStruct? IsObject? IsArray etc...
Point is, I could do a IsSimpleValue() (assume its string) else, carry out inspection on data types, then once i know, i do a final check to see if its empty AND then carry out another bunch of routines pertinant to the task at hand..point is, i'd roll that every time i use it unless i place it into a function lib of my own, which brings me back to the point of a "IsEmpty" :D *simple way to consolidate all xxIsEmpty methods into one..*
Basically purpose is, i want to inspect scopes, if context params exist within one of those scopes, carry out further instructions (audit purposes) but if they are empty or complex types, ignore them all together.
This does not demonstrate a requirement for isEmpty(). It demonstrates a need for structKeyExists() and isSimpleValue(). You'd still need to evaluate for existence (structKeyExists()), and after that your decision process doesn't need to differentiate between various sorts of data types; it simply needs to determine whether it's simple or not.
(IsSimpleValue) can be carried out AFTER i've determined that its full and Not an Object, otherwise no point in inspecting its type further...
(ie if NOT isObject(var) AND NOT IsEmpty(var) do xyz).
Its a passive way of inspecting scoped variables in what ideally would be an efficient way, especially since i won't necessarily "know" what type of scope/values are being passed in (well i personally know, but th object doesn't).
That would wash if you were simply taking about objects, but you're not.
If you're talking about objects, you'd have to define yourself what "empty" meant.
<cfset o = creatObject("component", "marmoset")> <cfset b = o.isEmpty()>
What's the automatic criteria here, for knowing whether o is empty?
If you're also including CF "primitives", you should be asking what's wrong with your code that you can't know when to expect a primitive or an object.
Or maybe I lack imagination.
Maybe..
>
fluffy function to bolt onto the CFML java/facade/java.lang.class thingy :)
You've hit it on the head. It would be a "fluffy function".
I'd rather them focus on constructors and interfaces before they thought about this sort of thing. Or <cfimap>. Or <cfimage>. Or making <cfwddx> and <cfcontent> work reliably. Or coping with "null" as a concept. Or decent file handling. Or porting the rest of the CFML tags to cfscript. Or handing out those neoprene beer cooler thingeys with each licence of CF.
ditto.. but anyway, it was a concept of consolidation of all xxIsEmpty whilst adding IsStringEmpty solution into one. Resulting in a uniformed approach to what CAN be if not careful a verbose approach to one or more problems. I guess others disagree, cool...
Scott zzzZzzzzzz...
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
