Mutability of RequestBuilder can cause very confusing behaviour about reboot HOT 4 CLOSED

Perhaps keep the existing functionality and add a new symbol to clear out the entire path?

from reboot.

On Fri, Nov 30, 2012 at 9:43 AM, Adam Shannon [email protected]:

Perhaps keep the existing functionality and add a new symbol to clear out
the entire path?

It's not just the path. It's all properties of the request. You can work
around all of these issues but using defs instead of vals.

from reboot.

Either leave the code as it is, and add an explanation in the docs, or

There is an explanation in the docs: http://dispatch.databinder.net/Defining+requests.html

Wrap RequestBuilder in an immutable wrapper whose methods always returns a new instance.

I decided not to do this early on, to keep Dispatch close to the underlying library's types (and so you can directly call methods on the underlying type, without implicit conversions).

The option I've mentioned a few times on the mailing list is that "someone" should contribute an immutable request builder to the underlying library, then Dispatch will use it. Fire up the old Eclipse and refactor some java! Tho, now that I think about it, the change is not backwards compatible for the underlying library so it should be a new request builder rather than a replacement for the old one.

from reboot.

Sorry, looks like I completely missed the massive warning in the docs. I'll close the issue.

from reboot.