Very good point Jared. I did think of that but I couldn't at the time think
of a reason why looping through the structure would be of any use but it's
obvious when you think about it. You don't 'need' to know the names of the
keys.
Isaac, you've given me an answer for something I'd given up on, I wrap my
SPs in functions some of the time, but because I don't want to call the SP
twice on one page I've always assigned to a local variable and then accessed
the resultset via that variable. For example:
<cfset qUser = GetUser(userID)>
<cfoutput>
#qUser.Username#
#qUser.Email#
</cfoutput>
What I would rather do, and this is purely for aesthetic reasons on my part,
is this:
<cfoutput>
#GetUser(userID).Username#
#GetUser(userID).Email#
</cfoutput>
And using your example of checking in the VARIABLES scope for the recordset
before calling the SP I can do that without two or more calls to the DB.
However, now I've thought about it, I'm beginning to favour the former.
How's that for fickleness?!
"And in general what I know of "encapsulation" says that things should
largely fallow the model of functions -- the black box (component)
doesn't require you to know how the internals work -- you provide
multiple inputs and get back a singular result. Put the car in reverse
(input 1) and step on the gas (input 2) and the car backs up (singular
result). You may know how the engine works to accomplish this, but
that knowledge is irrespective of your ability to produce the singular
desired result of backing the car."
Yes, but, you do need to know the public interface of an object which
includes what it returns if anything. So for this example you need to know
that putting the car in reverse and hitting the gas will back the car up.
You could argue that knowing exactly what a function returns has no baring
on it being less black boxed, regardless of it being a resultset, or a
struct of queries. At what point does it become too open:
- you know it returns a structure?
- you know it returns a structure with a key of myResultset?
- you know it returns a structure with a key that references a query?
- you know it returns a structure with a key that references a query that
has a column UserID?
I don't have a firm opinion on this, but if it's not the first line then I
don't think it would be anything other than the last.
"In a lot of cases we do end up returning structures from functions,
but in general my thinking is that if it's possible to return a
structure, then in most cases, particularly when the content of the
structure is varied and complex such as queries, there should also be
a consistent syntax to produce any of the individual values in that
structure independent of the structure itself, whether that's
getNameOfStructureKey() or getProperty("nameOfStructureKey") (my
preference). At this point the function which returns the structure is
merely a convenience afforded for the sake of processes which utilize
a large amount of the returned data at once, rather than needing only
certain discrete bits of it."
I see your point with this. Better to have:
#user.getProperty("username")#
#user.getProperty("password")#
#user.getProperty("email")#
than:
#user.getUsername()#
#user.getPassword()#
#user.getEmail()#
as a way of dealing with structures or queries. The former could deal with
ever increasing/decreasing resultset rows, add a new column,
user.getProperty("hairColour"), take a column away and you don't have
redundant methods that need removing. But, if you know the name of a struct
key/query column, what's wrong with using it directly without going through
a method, getProperty("someKeyOrColumn")? Ok, it is more encapulated, but
there are ways around it that I wouldn't consider to be too much work to
implement.
If you start off with returning a query and all code that accesses it uses
query.column you could always maintain the returning of a query even if it
changes to something else. If they had a query to begin with, give a query
even when it's actually a structure/array/simple value.
I do like the getProperty() idea.
Anyway, it's 01:30 and my bed looks very inviting. Sorry if my ramblings
seem to contradict each other that's probably because they do! And d'you
know what I like about Isaac's and Jared's posts? They don't in any way seem
preachy. Which to me makes them damn fine posts :O)
Ade
-----Original Message-----
From: Jared Rypka-Hauer - CMG, LLC [mailto:[EMAIL PROTECTED]
Sent: 03 March 2005 23:39
To: CF-Talk
Subject: Re: Stored Procedures in a CFC
On Thu, 3 Mar 2005 20:51:45 -0000, Adrian Lynch
<[EMAIL PROTECTED]> wrote:
> I don't see how using structures over arrays improves encapulation.
Granted
> standardising the naming of the resultsets will help but how can it be
> better in having to know the names of two variables inside another
> function/cfc method?
>
> Good call on the value/reference point though, that always slips me by.
>
> Ade
I don't really see how it aids enapsulation either, but I do know that
you don't need to know the names of your collection elements in order
to loop it:
<cfloop collection="#dataStruct#" item="i">
#i# = #dataStruct[i]#<br>
</cfloop>
This gets access to your collection (structure variable) the same way
an index loop would get you access to an array:
<cfloop from="1" to="#arrayLen(myArray)#" index="i">
#myArray[i]#<br>
</cfloop>
However, because of the structure's properties as an associative
array, you have the extra readability and clarity when using cfoutput
in a loop, cfdump, or any other method to reveal your variable's
contents. Add to that the byRef (pass) vs. byVal (copy) difference
between the two and I think there's compelling reason to use structs
where possible instead of arrays.
Aside from that, now that we have the ability to use array-style
notation on structs, from a basic coding perspective there's no real
difference other than the aforementioned benefits. And I don't think
the numerical aspects of an array's indexing versus string indexes in
a struct provide enough of a performance boost to justify the
sacrifice of readability (which amounts to maintainability) and
clarity.
Laterz,
J
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.6.0 - Release Date: 02/03/2005
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Discover CFTicket - The leading ColdFusion Help Desk and Trouble
Ticket application
http://www.houseoffusion.com/banners/view.cfm?bannerid=48
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:197401
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
