6 deleted 2158 characters in body
source | link

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

Take a vector drawing or CAD application as an example. If a user selects a segment of a poly line sequence and uses a scale tool to shrink that line down to zero length with two coincident points, should the coincident points be fused/merged into one with the segment removed or not?

A zero-length line segment isn't always useless if the user can interact with the results. A user might squash a line to zero and then drag on a point (at which point you can just select the first point in the segment when both points are coincident) away from where it was and now the segment is valid and has length again. If that's a use case that the software wants to support, then it becomes extremely awkward to get around the fact that the LineSegment would want to throw in that case. When you throw from LineSegment's ctor, it's either very mildly helpful for a software that wants to disallow this case as well, or a headache-inducing obstacle if the software wants to allow this case, so that's why I suggest to err on not throwing.

But anyway, that's an end-user design question and maybe the proper design is to merge the points automatically for the user and remove the segment, or maybe it is not, but either way I wouldn't look to be solving these questions in the lowest level parts of the geometry library (the LineSegment class itself) unless you're willing to commit to a very firm design decision at such a central level. That might be something to be solved by, say, the higher level Shape or Geometry objects more specifically relevant to the software itself that use this library.

So if you have doubts and want to make these classes as widely applicable as you can, I'd try to support these cases if possible without throwing, and leave these more end-user design questions to be solved by code that's closer to the end-user level. Instead you might seek to just make it easier for the clients to detect these cases, having straightforward functions to see if a segment has a length of 0, see if a poly line has coincident points, offer functions to fuse coincident points and remove 0-length segments from a poly line, etc.

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

Take a vector drawing or CAD application as an example. If a user selects a segment of a poly line sequence and uses a scale tool to shrink that line down to zero length with two coincident points, should the coincident points be fused/merged into one with the segment removed or not?

A zero-length line segment isn't always useless if the user can interact with the results. A user might squash a line to zero and then drag on a point (at which point you can just select the first point in the segment when both points are coincident) away from where it was and now the segment is valid and has length again. If that's a use case that the software wants to support, then it becomes extremely awkward to get around the fact that the LineSegment would want to throw in that case. When you throw from LineSegment's ctor, it's either very mildly helpful for a software that wants to disallow this case as well, or a headache-inducing obstacle if the software wants to allow this case, so that's why I suggest to err on not throwing.

But anyway, that's an end-user design question and maybe the proper design is to merge the points automatically for the user and remove the segment, or maybe it is not, but either way I wouldn't look to be solving these questions in the lowest level parts of the geometry library (the LineSegment class itself) unless you're willing to commit to a very firm design decision at such a central level. That might be something to be solved by, say, the higher level Shape or Geometry objects more specifically relevant to the software itself that use this library.

So if you have doubts and want to make these classes as widely applicable as you can, I'd try to support these cases if possible without throwing, and leave these more end-user design questions to be solved by code that's closer to the end-user level. Instead you might seek to just make it easier for the clients to detect these cases, having straightforward functions to see if a segment has a length of 0, see if a poly line has coincident points, offer functions to fuse coincident points and remove 0-length segments from a poly line, etc.

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

5 added 101 characters in body
source | link

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

Take a vector drawing or CAD application as an example. If a user selects a segment of a poly line sequence and uses a scale tool to shrink that line down to zero length with two coincident points, should the coincident points be fused/merged into one with the segment removed or not?

A zero-length line segment isn't always useless if the user can interact with the results. A user might squash a line to zero and then drag on a point (at which point you can just select the first point in the segment when both points are coincident) away from where it was and now the segment is valid and has length again. If that's a use case that the software wants to support, then it becomes extremely awkward to get around the fact that the LineSegment would want to throw in that case... Or maybeWhen you throw from LineSegment's ctor, it's either very mildly helpful for a better usersoftware that wants to disallow this case as well, or a headache-end design is just automateinducing obstacle if the fusion/merging and notsoftware wants to allow this case at all, so that's why I suggest to err on not throwing.

But anyway, that's a useran end-enduser design question and maybe the proper design is to merge the points automatically for the user and remove the segment, or maybe it is not, but either way I wouldn't look to be solving these questions in the lowest level parts of the geometry library (the LineSegment class itself) unless you're willing to commit to a very firm design decision at such a central level. That might be something to be solved by, say, the higher level Shape or Geometry objects more specifically relevant to the software itself that use this library.

So if you have doubts and want to make these classes as widely applicable as you can, I'd try to support these cases if possible without throwing, and leave these more userend-enduser design questions to be solved by code that's closer to the userend-enduser level. Instead you might seek to just make it easier for the clients to detect these cases, having straightforward functions to see if a segment has a length of 0, see if a poly line has coincident points, offer functions to fuse coincident points and remove 0-length segments from a poly line, etc.

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

Take a vector drawing or CAD application as an example. If a user selects a segment of a poly line sequence and uses a scale tool to shrink that line down to zero length with two coincident points, should the coincident points be fused/merged into one with the segment removed or not?

A zero-length line segment isn't always useless if the user can interact with the results. A user might squash a line to zero and then drag on a point (at which point you can just select the first point in the segment) away from where it was and now the segment is valid and has length again. If that's a use case that the software wants to support, then it becomes extremely awkward to get around the fact that the LineSegment would want to throw in that case... Or maybe a better user-end design is just automate the fusion/merging and not allow this case at all.

But that's a user-end design question and maybe the proper design is to merge the points automatically for the user and remove the segment, or maybe it is not, but either way I wouldn't look to be solving these questions in the lowest level parts of the geometry library (the LineSegment class itself) unless you're willing to commit to a very firm design decision at such a central level. That might be something to be solved by, say, the higher level Shape or Geometry objects more specifically relevant to the software itself that use this library.

So if you have doubts and want to make these classes as widely applicable as you can, I'd try to support these cases if possible without throwing, and leave these more user-end design questions to be solved by code that's closer to the user-end level. Instead you might seek to just make it easier for the clients to detect these cases, having straightforward functions to see if a segment has a length of 0, see if a poly line has coincident points, offer functions to fuse coincident points and remove 0-length segments from a poly line, etc.

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

Take a vector drawing or CAD application as an example. If a user selects a segment of a poly line sequence and uses a scale tool to shrink that line down to zero length with two coincident points, should the coincident points be fused/merged into one with the segment removed or not?

A zero-length line segment isn't always useless if the user can interact with the results. A user might squash a line to zero and then drag on a point (at which point you can just select the first point in the segment when both points are coincident) away from where it was and now the segment is valid and has length again. If that's a use case that the software wants to support, then it becomes extremely awkward to get around the fact that the LineSegment would want to throw in that case. When you throw from LineSegment's ctor, it's either very mildly helpful for a software that wants to disallow this case as well, or a headache-inducing obstacle if the software wants to allow this case, so that's why I suggest to err on not throwing.

But anyway, that's an end-user design question and maybe the proper design is to merge the points automatically for the user and remove the segment, or maybe it is not, but either way I wouldn't look to be solving these questions in the lowest level parts of the geometry library (the LineSegment class itself) unless you're willing to commit to a very firm design decision at such a central level. That might be something to be solved by, say, the higher level Shape or Geometry objects more specifically relevant to the software itself that use this library.

So if you have doubts and want to make these classes as widely applicable as you can, I'd try to support these cases if possible without throwing, and leave these more end-user design questions to be solved by code that's closer to the end-user level. Instead you might seek to just make it easier for the clients to detect these cases, having straightforward functions to see if a segment has a length of 0, see if a poly line has coincident points, offer functions to fuse coincident points and remove 0-length segments from a poly line, etc.

4 added 193 characters in body
source | link

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

Take a vector drawing or CAD application as an example. If a user selects a segment of a poly line sequence and uses a scale tool to shrink that line down to zero length with two coincident points, should the coincident points be fused/merged into one with the segment removed or not?

A zero-length line segment isn't always useless if the user can interact with the results. A user might squash a line to zero and then drag on a point (at which point you can just select the first point in the segment) away from where it was and now the segment is valid and has length again. If that's a use case that the software wants to support, then it becomes extremely awkward to get around the fact that the LineSegment would want to throw in that case... Or maybe a better user-end design is just automate the fusion/merging and not allow this case at all.

But that's a user-end design question and maybe the proper design is to merge the points automatically for the user and remove the segment, or maybe it is not, but either way I wouldn't look to be solving these questions in the lowest level parts of the geometry library (the LineSegment class itself) unless you're willing to commit to a very firm design decision at such a central level. That might be something to be solved by, say, the higher level Shape or Geometry objects more specifically relevant to the software itself that use this library.

So if you have doubts and want to make these classes as widely applicable as you can, I'd try to support these cases if possible without throwing, and leave these more user-end design questions to be solved by code that's closer to the user-end level. Instead you might seek to just make it easier for the clients to detect these cases, having straightforward functions to see if a segment has a length of 0, see if a poly line has coincident points, offer functions to fuse coincident points and remove 0-length segments from a poly line, etc.

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

Take a vector drawing or CAD application as an example. If a user selects a segment of a poly line sequence and uses a scale tool to shrink that line down to zero length with two coincident points, should the coincident points be fused/merged into one with the segment removed or not?

A zero-length line segment isn't always useless if the user can interact with the results. A user might squash a line to zero and then drag on a point (at which point you can just select the first point in the segment) away from where it was and now the segment is valid and has length again. If that's a use case that the software wants to support, then it becomes extremely awkward to get around the fact that the LineSegment would want to throw in that case... Or maybe a better user-end design is just automate the fusion/merging and not allow this case at all.

But that's a user-end design question and maybe the proper design is to merge the points automatically for the user and remove the segment, or maybe it is not, but either way I wouldn't look to be solving these questions in the lowest level parts of the geometry library (the LineSegment class itself) unless you're willing to commit to a very firm design decision at such a central level. That might be something to be solved by, say, the higher level Shape or Geometry objects more specifically relevant to the software itself that use this library.

So if you have doubts and want to make these classes as widely applicable as you can, I'd try to support these cases if possible without throwing, and leave these more user-end design questions to be solved by code that's closer to the user-end level.

Depends on context, but just generally speaking, if you don't know the answers to these questions, I would suggest to seek to make your LineSegment allow this case without throwing, and if possible, even find a way to allow your PolyLine cases to also work without throwing.

Take a vector drawing or CAD application as an example. If a user selects a segment of a poly line sequence and uses a scale tool to shrink that line down to zero length with two coincident points, should the coincident points be fused/merged into one with the segment removed or not?

A zero-length line segment isn't always useless if the user can interact with the results. A user might squash a line to zero and then drag on a point (at which point you can just select the first point in the segment) away from where it was and now the segment is valid and has length again. If that's a use case that the software wants to support, then it becomes extremely awkward to get around the fact that the LineSegment would want to throw in that case... Or maybe a better user-end design is just automate the fusion/merging and not allow this case at all.

But that's a user-end design question and maybe the proper design is to merge the points automatically for the user and remove the segment, or maybe it is not, but either way I wouldn't look to be solving these questions in the lowest level parts of the geometry library (the LineSegment class itself) unless you're willing to commit to a very firm design decision at such a central level. That might be something to be solved by, say, the higher level Shape or Geometry objects more specifically relevant to the software itself that use this library.

So if you have doubts and want to make these classes as widely applicable as you can, I'd try to support these cases if possible without throwing, and leave these more user-end design questions to be solved by code that's closer to the user-end level. Instead you might seek to just make it easier for the clients to detect these cases, having straightforward functions to see if a segment has a length of 0, see if a poly line has coincident points, offer functions to fuse coincident points and remove 0-length segments from a poly line, etc.

3 added 193 characters in body
source | link
2 added 277 characters in body
source | link
1
source | link