Hi, Depends on there being the intention to have it as parameter type. If it's > designed to be passed around to functions I really don't want it to be an > array. I am maintaining a legacy codebase where arrays are being used as > hashmaps pretty much everywhere, and it's error prone. We lose all kinds of > features like "find usages" and refactoring key/property names. Silly typos > in array keys with no actual validation of any kind cause null values and > annoying to find bugs. > > I agree that hashmaps can be really easy to use, but not as data > structures outside of the function/method scope they were defined in. If > value vs object semantics are important here, then something that is > forward compatible with whatever structs may hold in the future could be > interesting. >
Yes, I agree here, even if we talk about simple data without behavior. But as the length of the current RFC also suggests, URIs have surprisingly lot of behavior, so I think it's natural to use OO for modelling them. Máté
