Try to clarify wording

[mlimber]

I found the phrasing a little hard to understand and had to read it several times to get it. I've tried to rephrase from what I "got".

[tituswinters]

Thanks for the patch - we'll get back to you soon-ish. Kind of a busy week just now, might wind up being Monday.

[mlimber]

No rush on my side. Thanks for caring. :-)

The main gripe I have about the revised text is the "is" vs. "has" notion, which is what I interpreted the original text to be getting at. The "has" language was floating behind the original text, and I have made it explicit (as it were) in my PR.

Construction by conversion, however, does not imply an "is" relationship in the static/dynamic polymorphic sense. To me "is" is too strong a term and is really overloading the idea of polymorphism (which is a little meta). For instance, converting a float to an int is a valid conversion, but while both are conceptually numbers, an int is not a float and there may be something lost (viz., precision, range, NaNishness, etc.).

Perhaps the distinction I'm looking for is better communicated as being between converting contructors and building constructors. The former can be implicit, while the latter should be explicit.

[tituswinters]

I think mostly we're phrasing it as "is" in the "these are Platonically the same thing" not "is" in the polymorphism "Square is a Shape" sense. But I agree it's .... subtle.

…

On Thu, Mar 1, 2018 at 2:10 PM mlimber ***@***.***> wrote: No rush on my side. Thanks for caring. :-) The main gripe I have about the revised text is the "is" vs. "has" notion, which is what I interpreted the original text to be getting at. The "has" language was floating behind the original text, and I have made it explicit (as it were) in my PR. Construction by conversion, however, does not imply an "is" relationship in the static/dynamic polymorphic sense. To me "is" is too strong a term and is really overloading the idea of polymorphism (which is a little meta). For instance, converting a float to an int is a valid conversion, but while both are conceptually numbers, an int is not a float and there may be something lost (*viz.*, precision, range, NaNishness, etc.). Perhaps the distinction I'm looking for is better communicated as being between converting contructors and building constructors. The former can be implicit, while the latter should be explicit. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#156 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL4o36MIBT5e2q3HdjJFR5zDgtVSfbWvks5taEe9gaJpZM4SYcXD> .

[manshreck]

Agree that "is" vs. "has" is problematic here. It's a loaded term in programming and it might lead people to think of polymorphism, etc. On the face of it, I think the clarification in the first paragraph is a good qualification, but I'm less happy with the second paragraph for those reasons stated above.

I think more accurately it's a uniqueness statement (do these parameters uniquely identify the constructed object), or perhaps a phrasing with respect to degrees of freedom would be better. The Request class has an implicit "state" of "direction" in addition to server, connection that makes it specifically a Request, rather than a Response, for example.

[mlimber]

I'll take another whack at it.

[mlimber]

Ping! Just noticed this never went anywhere. No worries if you reject.