On 7/5/07, Jaime Metcher <[EMAIL PROTECTED]> wrote:
My fixed mental model is "everything is an object".
Well, that's OK at a conceptual level but I think I'm already one step ahead in why you then have problems...
Where the language features aren't there to help out, they can be simulated or worked around - but this is harder, more error prone and usually slower than when they are.
Right, and this is where you are fundamentally missing out on the benefits of languages - you're not being idiomatic. There is an inherent tension between a pure model - a logical model - and the idiom of any given language - what you might call the physical model. This translation - between the logical and physical - is fundamental to creating idiomatic, maintainable programs in a given language. The "workarounds" you talk of are just an attempt to shoehorn a concept into an idiom. X11 was a classic example of this: objects in C. X11 had a variety of structures and all sorts of free-floating functions that simulated OO. It was a monstrosity (even tho' it worked) and it certainly wasn't very maintainable. Most of all, it wasn't idiomatic C. Instead of mapping the concept of objects to an idiom, the authors systematically replicated OO machinery directly in C, creating an entire layer of complexity above and beyond what the underlying C code needed. Motif went one step further, layering yet another layer of "fake OO" over X11. It was horrible to program in!
1. Classes aren't objects.
There are very few languages where this is true in general. Most languages deliberately choose *not* to do this because of either idiomatic or performance concerns. It's a great concept in your *design* but not in your implementation.
This can be worked around by creating a separate CFC, an instance of which will act as the class object.
...
The relationship between the class object and the instance object can be managed by convention.
This is simply just not idiomatic CF (nor idiomatic in many other languages either). Implementing a workaround is really just adding an (unnecessary) layer of abstraction for no real benefit - it's an artificial layer.
2. Query recordsets aren't objects.
That really depends on your point of view. They are an encapsulation of the raw data. The type of a query actually *is* an object - that's how it is implemented. CF provides idiomatic conveniences to hide the full object, however, to make it easier to use for developers.
The more common approach is to just work in the two modes - access instance data and behaviour via method calls for individual objects, direct query field access for record sets.
Yes, that is the more idiomatic approach. To be honest, the bean-wrapping-single-record is the non-idiomatic element (especially since, for most people, such a bean has no other behavior at all: it's just a 'dumb' data container).
second approach, you just have to remember that if you need to put complex behaviour in a getter (e.g. do an on-the-fly data migration for backward compatibility) you need to duplicate that behaviour in a SQL view and then base your query on the view rather than the base table.
But that's true regardless - if you change the implementation to introduce a data mapping, you have to account for that *somewhere* in your application. Making record sets into "true" objects in your mind wouldn't magically enable the data translation. You already have the gateway object that you could hide the mapping inside so you do not need to resort to views in the database. But, again, I think this is a case where you're trying to artificially wrap a change in requirements that is always going to have some impact somewhere.
drops me out of object-think and into thinking about how the plumbing works,
Because you're crossing the boundaries between logical and physical design too often. You're trying to think ahead and implement your design piecemeal. In other words, it isn't ColdFusion causing this cognitive dissonance - it's your own approach.
At the end of the day, I'm commited to learning the workarounds
I think you're automatically setting yourself up for a disconnect here because you view implementation as a "workaround" to design instead of accepting there are two design levels - and that is true of *every* language. I see no conflict between logical and physical design and I see no problem with physical design being different for each language. The key is to separate the two and keep the logical design "reusable". Does that help? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
