Can't these methods be put into a trait which just calls the implementing class' get() method so we don't have to duplicate (most of) the logic for these two (and possible more) classes (in the future)?

@shaedrich

Can't these methods be put into a trait which just calls the implementing class' get() method so we don't have to duplicate (most of) the logic for these two (and possible more) classes (in the future)?

Possibly. It's a little icky because the exception error message specifically reference the 'type' that is being accessed (e.g. 'configuration keys' vs 'array keys'). Solving that either means changing the exception errors even on the Config class (possibly breaking), or adding a helper function that each using class would have to implement to identify the 'type' of content being accessed.

If the thought was that this could be used elsewhere, it might be worth doing. An earlier attempt at making wide "Typeable" objects didn't go anywhere though (#51302), so I kept this as simple and to-the-point as possible.

Ah, I didn't know the Typeable PR—thanks for linking it 👍🏻

Yeah, what you mentioned makes this possibly tricky—perhaps too tricky to be a good and feasible alternative

Maybe it makes sense to make this available for Collection too 🤔