lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 5740: Add \post to defer context actions to end of time step (


From: dak
Subject: Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by address@hidden)
Date: Fri, 07 Feb 2020 08:00:48 -0800

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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]