Addressable::Template: Substitution with something that is not a Hash #133

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@levinalex

I'm trying to replace my ad-hoc URI-Template parser with Addressable::Template.

However, I don't have the substitutions in Hash form. The current Template implementation assumes that substitutions are Enumerable (it calls inject on mapping)

Not calling inject makes it possible to pass a lambda (or anything else that responds to [] as a substitute:

describe "Substituting from an optional block" do
  sub = lambda { |x| "foo-#{x}" }
  Addressable::Template.new("{bar}/{baz}").expand(sub).to_str.should == "foo-bar/foo-baz"
end

Ideally I'd like to change expand to take a block like so:

template.expand { |field| "foo-#{field}" }

but I'd like to hear what you think about changing the API in that way.

Template: Don't assume mapping is enumerable
this allows template expansions with lambdas or anything else
that responds to `[]`
@coveralls

This comment has been minimized.

Show comment Hide comment
@coveralls

coveralls Jul 30, 2013

Coverage Status

Coverage increased (+0%) when pulling 2bdeb5f on levinalex:expand-lambda into 18f2305 on sporkmonger:master.

Coverage Status

Coverage increased (+0%) when pulling 2bdeb5f on levinalex:expand-lambda into 18f2305 on sporkmonger:master.

@sporkmonger

This comment has been minimized.

Show comment Hide comment
@sporkmonger

sporkmonger Sep 27, 2013

Owner

I like this idea, but I'd like to see documentation updated for the methods that would start accepting anything that responds to [] as well as some responds_to? type checking with TypeErrors thrown to keep the exceptions from getting too cryptic. I generally consider NoMethodError a bug in the library.

Owner

sporkmonger commented Sep 27, 2013

I like this idea, but I'd like to see documentation updated for the methods that would start accepting anything that responds to [] as well as some responds_to? type checking with TypeErrors thrown to keep the exceptions from getting too cryptic. I generally consider NoMethodError a bug in the library.

@sporkmonger

This comment has been minimized.

Show comment Hide comment
@sporkmonger

sporkmonger Sep 27, 2013

Owner

Sorry BTW about the really late reply, somehow the email notification for this PR slipped through the cracks.

Owner

sporkmonger commented Sep 27, 2013

Sorry BTW about the really late reply, somehow the email notification for this PR slipped through the cracks.

@sporkmonger

This comment has been minimized.

Show comment Hide comment
@sporkmonger

sporkmonger Nov 4, 2016

Owner

Also interested in @therabidbanana's take on this PR.

Owner

sporkmonger commented Nov 4, 2016

Also interested in @therabidbanana's take on this PR.

@therabidbanana

This comment has been minimized.

Show comment Hide comment
@therabidbanana

therabidbanana Nov 6, 2016

Contributor

This seems entirely reasonable to me - documentation would probably be good.

Contributor

therabidbanana commented Nov 6, 2016

This seems entirely reasonable to me - documentation would probably be good.

@sporkmonger

This comment has been minimized.

Show comment Hide comment
@sporkmonger

sporkmonger Dec 21, 2016

Owner

@levinalex I like this change, but I'd like to see at least one more test covering the "anything else that responds to []" scenario as well as a documentation update, as @therabidbanana mentioned.

Owner

sporkmonger commented Dec 21, 2016

@levinalex I like this change, but I'd like to see at least one more test covering the "anything else that responds to []" scenario as well as a documentation update, as @therabidbanana mentioned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment