On 2020-04-07 12:28 p.m., Torsten Paul wrote: > On 07.04.20 16:52, Ron Wheeler via Discuss wrote: >> If accessing hidden implementation details becomes a >> common practice needed by many users of an API, then >> the parts of the implementation that are needed should >> be formally exposed in the API and documented. > Agreed, and that's what happens. The type test functions > are a good example. > >> Not really the case that I was talking about. >> My point is really about an accidental misunderstanding >> of the API resulting from an unintended behavior that >> violates the intention of the API and is not documented >> officially but has crept into the folklore of the user >> community. > I don't follow. It just makes it harder to change/fix, > but otherwise the issue is the same. Extra promotion > of the unintended use does not seem useful, instead > a deprecation warning might be the only way forward. That would apply if you offer an alternative function with a different signature and really and truly intend to remove the function in a future release. I have never heard of deprecating an undocumented part of a documented function. "We have heard that some people have found a way to use this function in an undocumented way to rotate the entire model rather than just the included parts by adding 1000 to each of the axis rotation coordinates. This usage is deprecated, please stop." At the start of this discussion, I thought that we were talking about people using an undocumented behavior of an otherwise useful feature. Probably to take advantage of a useful but undocumented side effect that had somehow become known to the community. I would expect that the fix would be to either fix the description to include the undocumented behavior in the official description or warn people that a certain behavior is considered to be a bug (Issue xx) and may cease to happen in a future release. I would not consider this to be promotion except to people who want to build landmines into their application that will explode at some future date without warning except in the release notes(if they are lucky). Anyone who would do this to themselves deserves whatever happens and have no moral right to complain when it does. Ron > ciao, > Torsten. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org -- Ron Wheeler Artifact Software 438-345-3369 rwheeler@artifact-software.com

Give you that one! Ron On 2020-04-07 2:20 p.m., Jordan Brown wrote: > On 4/7/2020 5:58 AM, Ron Wheeler via Discuss wrote: >> Isn't   "observed behavior that is not part of the designed >> functionality" the actual definition of a bug. > > No (and in a different way than Torsten mentioned).  Often there will > be cases that are formally undefined behavior, where the observed > behavior is something that you might want to rely on. For instance, in > JavaScript the order of enumeration of the elements of an object is > formally undefined, but in some implementations it is reliably the > same as the order that the elements were added.  It's very easy to > accidentally depend on this behavior, or to deliberately depend on it > without realizing that it's not a designed-in feature. > -- Ron Wheeler Artifact Software 438-345-3369 rwheeler@artifact-software.com

> But you said that when you want a face that's a different color you union on a thin sliver of the other color. Yes but only for vitamins that show in preview. They don't even have to be manifold, they just have to look the part. Anything I output as a 2D or 3D model to CNC route or 3D print is shown in the preview as a single colour applied at the top level of the object, after all the CGS ops. Sometimes the actual colour of the filaments and sheets I use. Sometimes contrasting colours to make assembly views clearer. On Wed, 8 Apr 2020 at 02:06, Ron Wheeler via Discuss < discuss@lists.openscad.org> wrote: > Give you that one! > > Ron > > On 2020-04-07 2:20 p.m., Jordan Brown wrote: > > On 4/7/2020 5:58 AM, Ron Wheeler via Discuss wrote: > > Isn't "observed behavior that is not part of the designed functionality" > the actual definition of a bug. > > > No (and in a different way than Torsten mentioned). Often there will be > cases that are formally undefined behavior, where the observed behavior is > something that you might want to rely on. For instance, in JavaScript the > order of enumeration of the elements of an object is formally undefined, > but in some implementations it is reliably the same as the order that the > elements were added. It's very easy to accidentally depend on this > behavior, or to deliberately depend on it without realizing that it's not a > designed-in feature. > > > -- > Ron Wheeler > Artifact Software > 438-345-3369rwheeler@artifact-software.com > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >