Configurable Separator

[mattsah]

I'm wondering if you'd be open to a configurable separator. I'd offer a pull request on 2.X non-BC breaking, which is what we're currently using, for a 2.5 version. While we don't have a preference I could see this working two different ways or both:

Idea # 1:

Given I can flatten('_') it seems I should also be able to do something like set($key, $value, '_') ... adding an optional $separator parameter to effectively any method interface that allows you to do notation parsing.

Idea # 2:

At least creating an internal $separator property, and having a general setSeparator() property which would allow for changing it and/or temporarily changing it and changing it back as needed.

Idea # 3:

A combination of both where instead of setSeparator() it's setDefaultSeparator() and you're still able to overload on a per method call basis.

If this is something you're open to, let me know and I'll get in a pull request. Again, our concern is on the 2.X version, but if you want to make the equivalent change on 3.X it should be pretty easy based on the pull request.

[adbario]

Thanks @mattsah for the well-prepared feature request 👍

As the library is specifically called dot-notation and using a dot separator is the most common practice in similar packages in different languages, I would prefer to keep the dot as a separator.

Specifically, your first suggestion with an optional separator on each method is something I would rather avoid.

But adding an optional separator to the constructor params is something we could implement, that would be simple and effective. I would leave the separate setter out though and instead use another instance with a different separator. This way there wouldn't be any confusion about the current separator per instance.

I'm happy to implement my suggestion above.

[mattsah]

While I understand the name, it does seem to me at least (maybe this is just how we use it) that flatten() was already designed with some of this in mind, particularly the idea that you might convert something from dot notation into say an underscore notation (as provided in the example). At least for us, we use this library to power an entire configuration language https://github.com/dotink/jin...

This creates some oddities with a few internal operations and how we merge, which are currently worked around by simply flattening a collection and then setting from the flattened keys.

This works well... until you have a key with a dot in it. Our goal was some kind of functionality that would allow us to flatten it with a much more explicit separator/token that's less likely to be used and then set with a similar separator.

Setting this at constructor time only is a no go because we still rely on the . for other INI-style parsed dot names in other areas.

This is why we either need per method or a way to set a default separator but change it effectively on demand. We need to flatten with something other than dot, then set with something other than dot.

I appreciate your response and willingness, but given that this is also in the 2.X branch, we'll probably just do some more overloading. We're already overloading some of these methods anyway for specialty functionality (https://github.com/dotink/jin/blob/master/src/Collection.php) and I'm guessing we can't expect too many more changes in 2.X now that 3.X is out.

Appreciate the response and willingness to implement anyhow.

[mattsah]

Actually, come to think of it. I think we can reach a compromise.

If it's added to the constructor, we can just modify our class to add a setSeparator, assuming the property is protected and we can still overload. That said, if it's something you want for 3.X I'd leave that up to you, but if it's something you'll accept for a 2.5 I can do the pull request.

Let me know if that makes sense.

[adbario]

Thanks @mattsah for your comments, well reasoned feedback and suggestions are always much appreciated.

I'll play around with this a bit and will get back to you soon. Likely will implement the optional construction param first as a separate task and will go from there.

I'd like to keep the library junior developer-friendly as well while keeping the main focus on the actual dot notation.

Give me a moment, I'll keep you up to date.

[mattsah]

I did a quick pull request anyway which I think is in line with constructor only option.

[adbario]

I did a quick pull request anyway which I think is in line with constructor only option.

Thanks mate, much appreciated. Added a couple of comments there for you but looks good.

[adbario]

@mattsah 2.5.0 is now released with your updates.