Criticism of CFCs and the So-Called Debugger

[steve_renker]

I am developing an web application that is complex enough to require object
orientation. It is a system for subjects (users) in a dietary study to hit a
website from a Pocket PC phone, navigate through menus of foods (that may also
lead to submenus), and enter what they ate at a meal into our database. (Typing
in the meal free-form is not sufficient for us because we want menus to jog the
user's memory and we need to categorize the foods eaten in a way that will lend
itself to statistical analysis.)

This is really a job for J2EE, but the boss doesn't want to introduce another
programming language into our environment, so I am left to try to make it work
in CFML using CFCs. It's gone mostly ok but the devil is in a couple of details
that are really bugging me and my code (pardon the pun):

1. There is no way to test for equality between two instances of the same CFC.
This makes rolling my own collection classes and frameworks (which I also
shouldn't have to do) really difficult. Yes, I can make an array of objects,
but keeping track of which object is at what index is a nightmare when things
can be removed and shifted around, and I can't iterate through an array and
search for the location of a specific object when I can't test for equality.

2. There is no way to cast a CFC to one of its superclasses. This ability is
used in several design patterns to work with objects at an abstract level,
making the system less "brittle" and more adaptive to change.

3. There used to be an interactive debugger, but Macromedia removed it with
CFMX 6 and hasn't put it back. The "debugger" that is left shows you all the
functions that were called and the state of your page at the end of a request,
but you have no way to stop an algorithm in the middle and examine your
variables before and after a certain function is called.

WTF!? When I get really desperate to examine something without a bunch of
<CFOUTPUT> tags (reminds me of my batch COBOL days), I run my test machine
under a Java debugger and wade through the generated code. Loose typing means
that there are a bunch of extra hoops to step through, and when I try to step
over some I inevitably step over the real function call that I was trying to
see inside.

Anybody got any tips or tricks to make this less painful?

Thanks,
Steve

[Rambo]

I hear you - loud and clear. I think you got it right staright off the bat
with "really a job for J2EE". Nonetheless:

For equality you could get round it by giving the CFC "id" propties, perhaps
randomnly generated and the calling methods to compare manually one instance
to another.

Could you ensure it was the same instance by storing the one copy in
application scope and using only that one?

>>> 2. There is no way to cast a CFC to one of its superclasses.

"steve_renker" <webforumsuser@macromedia.com> wrote in message
news:d4367a$7kg$1@forums.macromedia.com...

> I am developing an web application that is complex enough to require

object

> orientation. It is a system for subjects (users) in a dietary study to hit

a

> website from a Pocket PC phone, navigate through menus of foods (that may

also

> lead to submenus), and enter what they ate at a meal into our database.

(Typing

> in the meal free-form is not sufficient for us because we want menus to

jog the

> user's memory and we need to categorize the foods eaten in a way that will

lend

> itself to statistical analysis.)
>
> This is really a job for J2EE, but the boss doesn't want to introduce

another

> programming language into our environment, so I am left to try to make it

work

> in CFML using CFCs. It's gone mostly ok but the devil is in a couple of

details

> that are really bugging me and my code (pardon the pun):
>
> 1. There is no way to test for equality between two instances of the same

CFC.

> This makes rolling my own collection classes and frameworks (which I also
> shouldn't have to do) really difficult. Yes, I can make an array of

objects,

> but keeping track of which object is at what index is a nightmare when

things

> can be removed and shifted around, and I can't iterate through an array

and

> search for the location of a specific object when I can't test for

equality.

>
> 2. There is no way to cast a CFC to one of its superclasses. This ability

is

> used in several design patterns to work with objects at an abstract level,
> making the system less "brittle" and more adaptive to change.
>
> 3. There used to be an interactive debugger, but Macromedia removed it

with

> CFMX 6 and hasn't put it back. The "debugger" that is left shows you all

the

> functions that were called and the state of your page at the end of a

request,

> but you have no way to stop an algorithm in the middle and examine your
> variables before and after a certain function is called.
>
> WTF!? When I get really desperate to examine something without a bunch of
> <CFOUTPUT> tags (reminds me of my batch COBOL days), I run my test machine
> under a Java debugger and wade through the generated code. Loose typing

means

> that there are a bunch of extra hoops to step through, and when I try to

step

> over some I inevitably step over the real function call that I was trying

to

> see inside.
>
> Anybody got any tips or tricks to make this less painful?
>
> Thanks,
> Steve
>

[Rambo]

Sorry, hit send by accident (lucky I don't carry a gun)

>> 2. There is no way to cast a CFC to one of its superclasses.

Not quite sure which patterns you are referring to here - but you do know
that you can implement polymorphism with CFC's, don't you? I am sure you
did - I guess I am just not seeing the requirement you know of. Just in
case - you only ever need work with a base class/cfc and runtime method
binding will occur just as it does in java & C++.

>>. There used to be an interactive debugger, but Macromedia removed it with

CFMX 6 and hasn't put it back.

My biggest issue with CF - Macromedia could have done great things with
making a decent IDE for CF, but they did'nt. Don't expect Adobe to show much
interest in coldfusion either - CF is one dog that has most certainly had
its day!



"steve_renker" <webforumsuser@macromedia.com> wrote in message
news:d4367a$7kg$1@forums.macromedia.com...

> I am developing an web application that is complex enough to require

object

> orientation. It is a system for subjects (users) in a dietary study to hit

a

> website from a Pocket PC phone, navigate through menus of foods (that may

also

> lead to submenus), and enter what they ate at a meal into our database.

(Typing

> in the meal free-form is not sufficient for us because we want menus to

jog the

> user's memory and we need to categorize the foods eaten in a way that will

lend

> itself to statistical analysis.)
>
> This is really a job for J2EE, but the boss doesn't want to introduce

another

> programming language into our environment, so I am left to try to make it

work

> in CFML using CFCs. It's gone mostly ok but the devil is in a couple of

details

> that are really bugging me and my code (pardon the pun):
>
> 1. There is no way to test for equality between two instances of the same

CFC.

> This makes rolling my own collection classes and frameworks (which I also
> shouldn't have to do) really difficult. Yes, I can make an array of

objects,

> but keeping track of which object is at what index is a nightmare when

things

> can be removed and shifted around, and I can't iterate through an array

and

> search for the location of a specific object when I can't test for

equality.

>
> 2. There is no way to cast a CFC to one of its superclasses. This ability

is

> used in several design patterns to work with objects at an abstract level,
> making the system less "brittle" and more adaptive to change.
>
> 3. There used to be an interactive debugger, but Macromedia removed it

with

> CFMX 6 and hasn't put it back. The "debugger" that is left shows you all

the

> functions that were called and the state of your page at the end of a

request,

> but you have no way to stop an algorithm in the middle and examine your
> variables before and after a certain function is called.
>
> WTF!? When I get really desperate to examine something without a bunch of
> <CFOUTPUT> tags (reminds me of my batch COBOL days), I run my test machine
> under a Java debugger and wade through the generated code. Loose typing

means

> that there are a bunch of extra hoops to step through, and when I try to

step

> over some I inevitably step over the real function call that I was trying

to

> see inside.
>
> Anybody got any tips or tricks to make this less painful?
>
> Thanks,
> Steve
>

[steve_renker]

> For equality you could get round it by giving the CFC "id" propties, perhaps

> randomnly generated and the calling methods to compare manually one instance
> to another.
> Could you ensure it was the same instance by storing the one copy in
> application scope and using only that one?

For those keeping score at home, I got what I needed to do done by shimming
around it this way:
First, I created this wonderfully productive Java class:

package edu.emory.sph.util;
public class EqualityTester {
public static boolean equal(Object a, Object b) {
return (((Object)a) == ((Object)b));
}
}

Then, I used it in my CFC like so:

<cfcomponent output="no">
<!--- The component stores its collection in a Java object of class
java.util.ArrayList. --->
<!--- The iterator function called below simply returns the ArrayList's
iterator. --->
<cffunction name="remove" returntype="boolean" access="public">
<!--- Return true if the item was there and has been removed, false if
not --->
<cfargument name="item" type="PERL.Model.Food" required="yes">

<cfobject name="tester" type="java" action="create"
class="edu.emory.sph.util.EqualityTester">
<cfset iter = this.iterator()>
<cfloop condition="iter.hasNext()">
<cfset iteratedItem = iter.next()>
<cfif tester.equal(iteratedItem, arguments.Item)>
<cfset iter.remove()>
<cfreturn true>
</cfif>
</cfloop>
<cfreturn false>
</cffunction>
</cfcomponent>

NOTE: Testing for equality in this way requires that the two object variables
refer to the exact same object (which is
what I wanted). My function as given will return false if given two different
object instances that are initialized with the
exact same data. To test for that kind of equivalence, I think you would need
to iterate through your Variables scope
and test equality on each variable inside.

[Rambo]

what a man! Do you do autographs?

But you know, I was just about to mention that ...


"steve_renker" <webforumsuser@macromedia.com> wrote in message
news:d45ptv$7hd$1@forums.macromedia.com...

> > For equality you could get round it by giving the CFC "id" propties,

perhaps

> > randomnly generated and the calling methods to compare manually one

instance

> > to another.
> > Could you ensure it was the same instance by storing the one copy in
> > application scope and using only that one?

>
> For those keeping score at home, I got what I needed to do done by

shimming

> around it this way:
> First, I created this wonderfully productive Java class:
>
> package edu.emory.sph.util;
> public class EqualityTester {
> public static boolean equal(Object a, Object b) {
> return (((Object)a) == ((Object)b));
> }
> }
>
> Then, I used it in my CFC like so:
>
> <cfcomponent output="no">
> <!--- The component stores its collection in a Java object of class
> java.util.ArrayList. --->
> <!--- The iterator function called below simply returns the

ArrayList's

> iterator. --->
> <cffunction name="remove" returntype="boolean" access="public">
> <!--- Return true if the item was there and has been removed,

false if

> not --->
> <cfargument name="item" type="PERL.Model.Food" required="yes">
>
> <cfobject name="tester" type="java" action="create"
> class="edu.emory.sph.util.EqualityTester">
> <cfset iter = this.iterator()>
> <cfloop condition="iter.hasNext()">
> <cfset iteratedItem = iter.next()>
> <cfif tester.equal(iteratedItem, arguments.Item)>
> <cfset iter.remove()>
> <cfreturn true>
> </cfif>
> </cfloop>
> <cfreturn false>
> </cffunction>
> </cfcomponent>
>
> NOTE: Testing for equality in this way requires that the two object

variables

> refer to the exact same object (which is
> what I wanted). My function as given will return false if given two

different

> object instances that are initialized with the
> exact same data. To test for that kind of equivalence, I think you would

need

> to iterate through your Variables scope
> and test equality on each variable inside.
>

[Mike Greider]

All components extend the base 'component.cfc'. In that file, you can add a
function to set a uuid. Than you can call this function to compare the object's
unique id. Hal Helms talks about this on his website. May want to check that
out.

[Adam Cameron]

> All components extend the base 'component.cfc'. In that file, you can add a

> function to set a uuid. Than you can call this function to compare the object's
> unique id. Hal Helms talks about this on his website. May want to check that
> out.

That doesn't really help. Consdier this:

// make a MyClass obj
o1 = createObject("component", "MyClass");

// set its property
o1.setProperty("value");

// make another one
o2 = createObject("component", "MyClass");

// with the same property value
o2.setProperty("value");

// see if they're equal
if (o1 eq o2){
// yep
}else{
// nup
}

Ignoring Hal Helms' UUID idea (which would automatically make these two
objects not equal), one should be able to do something along the lines of
the if() statement to see if the objects are equal (have the same member
data). Can't do it in CF.

Helms' idea would work if you wanted to see if one variable was a pointer
to the same object as another variable, though (same as Steve's idea).
Kinda useful, but not what one wants to do, a lot of the time.

// same pointer
o3 = o1;

if (o1.getUuid() eq o3.getUuid()){
// yep
}else{
// nup
}

In situations in which you want to see if one object "equals" another
object, it's up to the developer to determine what constitutes equality as
far as their class is concerned, and roll-their-own method to do it. Way
back when I did C++ (>10 years ago, so forgive my rustiness and potential
out-of-dateness), that was the case. Has Java worked out a way to automate
this? How does it do it?

--

Adam

[steve_renker]

> In situations in which you want to see if one object "equals" another

> object, it's up to the developer to determine what constitutes equality as
> far as their class is concerned, and roll-their-own method to do it. Way
> back when I did C++ (>10 years ago, so forgive my rustiness and potential
> out-of-dateness), that was the case. Has Java worked out a way to automate
> this? How does it do it?

In pure Java, a lot of the collection classes define the equality method as
the result of iterating over all the members of the collection and seeing
whether those are equal. Likewise in CFC, if all of the instance variables are
simple types (i.e., not CFCs themselves), you could loop over
StructKeyList(Variables) in one instance and test for IsDefined("Variables." &
Key) and equality in the other. If some of your instance variables are
themselves CFCs, it gets hairier, though I guess you could GetMetaData() on it
and if it's a CFC, call a custom equality function. (Which in a nice big object
graph, would go on and on ad nauseum.)

[steve_renker]

I should add that the thing that frustrates me most about CFML is that it
offers just enough metaprogramming capability to make me think I have options
in these situations, but usually I find that some detail is missing that causes
my scheme not to work. (Only after I have written half of my code already.)

[Adam Cameron]

> I should add that the thing that frustrates me most about CFML is that it

> offers just enough metaprogramming capability to make me think I have options
> in these situations, but usually I find that some detail is missing that causes
> my scheme not to work. (Only after I have written half of my code already.)

Welcome to the club.

--

Adam

[Mike Greider]

Not to start a flame war, but is this the fault of CF? The documentation is
pretty thorough.

Anyways, back to your real issue. If CF is limited in this area, can't you
just push the functionality down to Java? Granted, my Java skills are quite
humble, but the real benefit of CF is RAD development, with the ability to push
down deeper if you need to. I, for one, do not want them to continue to push
more and more complexity into the language. That's why I picked CF in the first
place, and especially why I've stuck with it after MX. It makes 80% of my work
50% faster.

[Adam Cameron]

>> In situations in which you want to see if one object "equals" another

> > object, it's up to the developer to determine what constitutes equality as
> > far as their class is concerned, and roll-their-own method to do it.

> In pure Java

[etc]

Sure. I know how to do it. I was more pointing out that your original
issue - "1. There is no way to test for equality between two instances of
the same CFC. " - is just as much the case in other languages too. So not
really a valid condemnation of CF in and of itself.

Or am I missing something?

--

Adam

[steve_renker]

Your point is very valid... but try getting my boss to see it that way. "One language to rule them all" is the problem I'm facing here.