On Fri, Oct 28, 2022 at 12:23 PM Joshua Rüsweg via internals < internals@lists.php.net> wrote:
> Hi > > > You can find the RFC at: > > > > https://wiki.php.net/rfc/randomizer_additions > > Tim Düsterhus and I have updated the RFC and have broadly adopted the > proposals. > > Firstly we have renamed the `getBytesFromAlphabet` to > `getBytesFromString` as Larry Garfield suggested. > > Secondly, we have extended the getFloat method with a parameter that > specifies which type of interval should be generated (Open, Closed, > Right Half-Open and Left Half-Open). > > Are you happy with the enum names? Have you any other suggestions? > > I had a discussion with Tim about this naming topic as well, and want to convey my suggestion along with the reasoning. I think the enum should be `Random\IntervalBoundary` with the enum cases: `IntervalBoundary::Open` `IntervalBoundary::Closed` `IntervalBoundary::OpenRight` or `IntervalBoundary::HalfOpenRight` `IntervalBoundary::OpenLeft` or `IntervalBoundary::HalfOpenLeft` First, I think the enum should be `IntervalBoundary` because an enum is used to explicitly represent a program state in a human readable format. Because of this, I think that the readability for enums should be the highest priority, even above brevity. Additionally, it should describe the thing that has the properties, in this case the interval itself. These interval settings are *not* a property of floats, it's just that interval boundary types don't usually matter outside of floats. The enum should be in the `Random\` namespace, because we are only guaranteeing that this is a complete list of interval boundary properties in the domain of random numbers. It should not be in the `Random\Randomizer` namespace, even though that's the only place it would be used, because these properties of an interval boundary would be shared by anything that has interval properties in the domain of random numbers. Enums don't describe a hierarchy, like interfaces do, so it doesn't make sense to me to do it the same way the engines are done, for example. I think `OpenRight` and `OpenLeft` are clear enough, since it clearly describes something that is only half open, but I wouldn't argue strongly against `HalfOpenRight` and `HalfOpenLeft` if someone else felt strongly about it. Anyway, that's my notes. :) Jordan
