Re: Re: RFC [Discussion]: Randomizer Additions

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