I chain methods every day. I couldn't imagine CF w/o it. The sample
above... doesn't do the same thing.
<cfset foo.setThis()
.setThat()
.setThisHereThingie()>
than
<cfset foo.setThis()>
<cfset foo.setThat()>
<cfset foo.setThisHereThingie()>
The first example says that "ThisHereThingie" lives inside of "That" which
lives inside of "This". The second example says "This", "That" and
"ThisHereThingie" live inside of "foo".
Method chaining saves a lot of typing and is easier to read (in my
opinion). This sort of thing is very common my code...
<cfset foo = getFooService().getFooByProperty("property") />.
The replacement for this... using a new line for each method call...
<cfset fooService = getFooService() />
<cfset foo = fooService.getFooByProperty("property") />
That's 34 extra chars of nebulous typing. If I'm going to use
"getFooService()" multiple times in the same page/code, I might store it in
a variable. Otherwise, I feel it's a waste of keystrokes. Your mileage may
vary.
Jason
On Sun, Jan 4, 2009 at 8:17 AM, Zac Spitzer <[email protected]> wrote:
>
> i'd like to see something like support in CF for a javascript style with()
>
> On Mon, Jan 5, 2009 at 1:11 AM, Marc Esher <[email protected]> wrote:
> >
> > i've adopted this style within the last year and have settled on it as
> > a standard. I had the same problem that Zac states, because I tried
> > using method chaining to reduce number of lines -- but I had it within
> > the context of Hibernate and criteria queries, so I started doing
> > this:
> >
> > result = session.createCriteria(My.class)
> > .add(....)
> > .add(....)
> > .add(....)
> > .list();
> >
> >
> > And that's what I do for CF, too.
> >
> > It doesn't reduce the number of lines, but it looks less verbose in
> > context, and that's my goal with chaining. I'd rather see:
> >
> > <cfset foo.setThis()
> > .setThat()
> > .setThisHereThingie()>
> >
> > than
> >
> > <cfset foo.setThis()>
> > <cfset foo.setThat()>
> > <cfset foo.setThisHereThingie()>
> >
> > for what it's worth, I think method chaining's goal is clarity and
> > compactness, not so much reduction in lines.
> >
> > best,
> >
> > marc
> >
> > On Sun, Jan 4, 2009 at 6:20 AM, Alan Livie <[email protected]> wrote:
> >> Thanks Zac. That's one reason I hadn't thought of.
> >>
> >> ________________________________
> >> From: Zac Spitzer <[email protected]>
> >> To: [email protected]
> >> Sent: Sunday, January 4, 2009 10:12:35 AM
> >> Subject: [CFCDEV] Re: Method chaining
> >>
> >>
> >> i have seen sometimes with CF is that exceptions with this style ( or
> >> nesting ) throw
> >> somewhat confusing error messages, i found that CF is easier to debug
> with
> >> the
> >> classic line at a time
> >>
> >> z
> >>
> >> On Sun, Jan 4, 2009 at 8:50 PM, Alan Livie <[email protected]> wrote:
> >>>
> >>> I have just read some code in a Hibernate book that uses a lot of
> >>> method chaining ie setFoo(1).setBar('myvar').setThis(x).setThat(y) etc
> >>>
> >>> I remember some old Open University days doing Smalltalk when method
> >>> chaining was common as there was no VOID return type on methods so
> >>> setter methods tended to return THIS.I have also seen this a lot
> >>> recently doing jQuery work ie $("a").addClass("test").show().html
> >>> ("foo"); The methods return the jQuery object so chaining is possible.
> >>>
> >>> In CF (at least the code I've read and written) we don't tend to do
> >>> this.
> >>>
> >>> Is this for readability reasons or something else I'm not aware of?
> >>>
> >>> I think setter methods (and maybe other methods that return VOID)
> >>> returning THIS is a sensible idea so we can chain or not chain as we
> >>> see fit.
> >>>
> >>>
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> Zac Spitzer -
> >> http://zacster.blogspot.com
> >> +61 405 847 168
> >>
> >>
> >> >
> >>
> >
> > >
> >
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com
> +61 405 847 168
>
> >
>
--
Jason Durham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
