> umm, reason being is rather then writing procedures yourself over and
> over (whether you share a lib or not) it would be ideal to simply go "is
> this variable empty... based on its type or not"...
I'm with Steve.
I am still to understand when you'd really be in a position to be so
not-in-control of your own data that you really don't know what sort of
comparison to be performing on it.
Given one of my more weak moments, I might find a function either returning
a struct (what I want), or a FALSE (it went tits up). BUt that's only when
I wasn't really thinking about what I was doing.
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".
Even if - every now and then - some ambiguity crops up, is it really a good
use of MM's time to provide for it?
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
Yeah... the beer cooler idea. I like that.
Adam
---
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/
