On 2020/02/07 15:43:30, Dan Eble wrote: > On 2020/02/07 09:19:03, hanwenn wrote: > > On 2020/02/06 14:29:55, Dan Eble wrote: > > More code means more maintenance liability, so unless > > it either solves a problem, or it simplifies the existing system, it would be > a > > net negative. > > You're preaching to the choir. > > > I would really like the problem defined before we try solving it. > [...] > > I hope I am not demoralizing you > > It's a good thing you threw in that last part, because from over here it was > sounding rather like you resented my posting this for review. I'll try to keep > my reply descriptive. > > I have seen that mailing-list discussions on detailed design--even for features > people recognize they need, but especially for those they don't--do not go far > or fast. I suppose it's because few people have the level of familiarity, the > current interest, or the time to devote to written communication on those > topics. I'm not blaming them; it's just my diagnosis. Posting a review gives > them something concrete to comment on, and that gets a discussion going. > > I have the sense that most of my successful contributions have gone this way. > Is this approach as effective as one that might be taken by a professional > software development team? No, but my code is in LilyPond. Are the factors > that make this the most effective approach in this context going to change? Not > likely. > > > I hope I am not demoralizing you > > Well, it's a dilemma: friction either way. I spent an hour composing this > reasoned reply. What I was hoping for was any of the following kinds of > feedback. Looking past the little lecture on process, I see some of them > starting to come through; so, thank you. > > 1. pointers to potential applications (thanks, David et al.) > 2. The implementation looks sane, but I can't think of a place we would use this > currently. I think you should ping us when your experiments with it are more > mature. > 3. I haven't looked at the implementation, but I can't think of a place we would > use this currently. I think you should ping us when your experiments are more > mature. > 4. You can approximate this already with X; would that work for you? > 5. Speaking as a user, I'm not sure where I'd apply this, but calling it X would > be more appropriate. > 6. This is fantastic! I've been working around not having this for decades!
Well, the problem is that this triggers some actions at a comparatively obscure time. As Han-Wen quite correctly states, that doesn't seem like something an end-user might need, and as omnipotent developers, if we needed that kind of functionality in some specific purpose, we could access it in C++. But that doesn't mean that it might not solve some task that a power-user, the growing breed of users working wonders in Scheme, might solve as part of a larger package. Would any such task benefit from clearer or different semantics? It's really hard to know. https://codereview.appspot.com/581600043/
