Iterator adapters - self function pointers

[JeffG]

Just wanted to throw out a thought regarding iterator adapters. The motivation comes from "typical" javascript applications where promises are heavily used, and often in multiple nested scenarios. Some devs are lured by not having to create a function for the callback, but readability goes out the window.

As an alternate to this (for some scenarios)

.filter([param1]{
     ....
})

.filter(self.my_filter)

• no need to spell out the parameters (as they just the function's parameters)
• functions are named, so readability goes up 10x

Thoughts?

[mjbshaw]

Can you provide a full example? I'm not sure how to interpret the idea and it looks like Markdown mangled some of the post?

[semicoleon]

I think you're describing implicit method closures?

So func(|x| value.method(x)) could be replaced with func(value.method)

[JeffG]

Never mind on this. It already works as I expected. Sorry about this, I'll delete this. I never see any example that reference named function for iterator adapters, always stuff in. Most of the time, not really "closing" over anything, just a function pointer, which works as is (to put function name in the iterator adapter) - it's perfect as is. my bad on this.

[JeffG]

yeah, exactly, which seems to work as is actually. I was just using a module fn in my test, but worked fine. I'm gonna delete post.

[jdahlstrom]

A "self.function" syntax that closes over the self argument could still be a useful feature; for example Java does have it (spelled this::method) and C++ has had the mem_fn adapter for a long time (although granted it was more useful before lambdas were added).

[cuviper]

Note that self.x and self.x() can already exist as separate things -- accessing a field and a method. That's why you have to use parentheses to invoke a callable field, like (self.x)().

syntax	effect
self.x	access field x
(self.x)()	call field x
self.x()	call method x
|| self.x()	capture self in a closure calling method x

[JeffG]

Thanks