Use Value Objects rather than massive $options arrays when exposing an interface for configuring requests made by your SDK, because you want to make your SDK code as self-documenting as possible. - @SecondeJ#phptek
@ian@SecondeJ on an actual more serious note of that though i've considered taking that so far as to even eliminating constructor args. but then i feel like that would be insane every class always being a set of two.
@afilina@ian@SecondeJ Apples and oranges; he was talking SDK, not application. And every framework uses arrays for app config, to allow merging values into vendor and extension defaults. Some just call those arrays "YAML".
(I'd like to change our libraries to define options value objects, and then have our factories create those from config arrays, as that gives the option to eliminate the arrays. But config merging provides much needed flexibility and overriding power for users.)
@Crell@mwop@afilina@ian@SecondeJ Yes, that sort of approach is what I was trying to describe. You get the flexibility of merging and key/value, but end up with typed value objects.
My point was that the OP was around configuring SDKs, which are narrowly scoped, vs an entire application, which is an aggregate, and which may need merging of config between extensions and user-supplied values. Ideally, that all becomes value objects at some point.
@mwop@ian@SecondeJ Symfony manages to do this well though. I just can't go back to any anonymous data structures anymore. I'm saying it's worth a look. I feel like the flexibility argument is similar to using dynamic typing in PHP in general. Sure, it's flexible, but at what cost?
Add comment