Maybe we should switch to kwargs for this feature?

@solnic I thought about it, it's not gonna work, you still need to access local variable with reserved words

proc { |when:| "how to access >when< here?" }

I guess binding.local_variable_get is a bit too much to ask of end users.

Another option if using kwargs would be to splat them and pull it off the hash:

proc { |**args| "we can get it as #{args.fetch(:when)}" }

@timriley ** not gonna work either, rom-factory uses deps for figuring out the order in which callable values have to be called (via tsort).

@flash-gordon Ah, of course. Well in this case a trailing underscore sounds like the least worse solution 😅

@solnic @flash-gordon @timriley I know is not ideal but shall we push it?

OK I need to think about this. Maybe this should be based on lazy evaluation, ie pass an object and whenever you call a method on it, it will generate a value based on factory definition. ie

f.email { fake(:internet, :email) }
f.login { |s| s.email }

@solnic this can be slower because may require a wrapper but I'm not sure

@flash-gordon yeah but it won't require tsorting

@solnic sorting is required just once whereas wrapping is required on every instantiation, no?

@flash-gordon no, we need to create a wrapper for each factory object, so once per factory definition, then we just pass this one to each block when required

@solnic @flash-gordon I can have a look and try to implement it, or is anyone interested in do it?

@GustavoCaso depends on whether @solnic's thinking process complete :)

Yeah I'd at least try to do it using a wrapper with injected factory, so that it can delegate to it in order to return a value from a factory. If we make it coercible to a hash, then as a bonus something like f.foo { |bar:| } would make bar available via wrapper object, which I think would be cool.

So, Gustavo, if you're interested in experimenting with this, I'd say go ahead :)

|bar:| won't work, only |bar:, **| will

@flash-gordon gahhh right ;( but it still makes sense to experiment with this

Closing due to lack of activity. The related issue remains open, so we should revisit this before 1.0.0.