Re: Unapplied patches
Posted: Sat Feb 15, 2014 6:35 pm
@kobi7, no worries. There's good points on all sides here.
--
ticket:34 is prime example of something undecided. Do we want to continue to overload the "is" keyword? Do we want to tell people that in the middle of an expression "is" will mean object identity if they are implementing a method, but it will mean member visibility if they are implementing a var, but back to object identity if it's a property...
Well actually "is" still means "visibility" outside the method or property body.
I guess since no one has come up with a proposal to split "is" up into two words that we actually like, so I'll go with the last patch on the ticket.
But note that when I reviewed the ticket from top to bottom, I loved your comments here (emphasis mine):
"""
When I finished what I was doing and stopped fuming I had another pass over this report and the patches to date - both of which I now dislike nearly as much as I dislike the current status quo
"""
If I had applied the first patches, which I bounced with stated reasons, you would have ended up with something you didn't even like!
Btw I don't think I ever feel the weight of what ticket:34 addresses because I have a habit of always putting my "shared" members in a "shared" section, plus I use the underscores for protected and private. ... In case you were wondering why this never bothered me. Unlike Cobra internal exceptions, it just doesn't halt my app development.
--
Regarding these bugs you didn't know about, are you developing applications with Cobra? That's how I'm finding these things.
And being in the middle of building whatever app, I don't have time to post the ticket and wait an unspecified number of days to see if they'll be fixed. When you see me push a fix straight in that usually means I was building something in Cobra when I got interrupted by the bug. I make the fix and continue development.
--
And yes ticket:356 "silent contract on streams" is pretty bad. About 100 X worse than deprecating the old for-statement (ticket:8). Contracts throw exceptions when their conditions are not met. So when you don't get that exception, you know the conditions were met and now you're reasoning about a bug with false information. You can waste a lot of time in that way and I did.
--
You asked about throughput of patch applications, which is a fair question. I have been hoping for some time that by (1) reducing the addition of new features, (2) not implementing pet projects and (3) focusing on fixes that are showstoppers during app development... that the showstoppers would go away.
To some extent they have. I did a web app recently and ran into 3 problems which is fewer than I have run into on previous projects that had less code.
--
@nerdzero: I don't see how a megapatch would fix your issue with testify. And yes patches are more work than they would seem upfront. And no, I don't think one unified patch will be helpful.
--
Going forward, I will budget time in my week, every week (sans vacation or illness), to look at patches. ticket:34 is now in.
--
ticket:34 is prime example of something undecided. Do we want to continue to overload the "is" keyword? Do we want to tell people that in the middle of an expression "is" will mean object identity if they are implementing a method, but it will mean member visibility if they are implementing a var, but back to object identity if it's a property...
Well actually "is" still means "visibility" outside the method or property body.
I guess since no one has come up with a proposal to split "is" up into two words that we actually like, so I'll go with the last patch on the ticket.
But note that when I reviewed the ticket from top to bottom, I loved your comments here (emphasis mine):
"""
When I finished what I was doing and stopped fuming I had another pass over this report and the patches to date - both of which I now dislike nearly as much as I dislike the current status quo
"""
If I had applied the first patches, which I bounced with stated reasons, you would have ended up with something you didn't even like!
Btw I don't think I ever feel the weight of what ticket:34 addresses because I have a habit of always putting my "shared" members in a "shared" section, plus I use the underscores for protected and private. ... In case you were wondering why this never bothered me. Unlike Cobra internal exceptions, it just doesn't halt my app development.
--
Regarding these bugs you didn't know about, are you developing applications with Cobra? That's how I'm finding these things.
And being in the middle of building whatever app, I don't have time to post the ticket and wait an unspecified number of days to see if they'll be fixed. When you see me push a fix straight in that usually means I was building something in Cobra when I got interrupted by the bug. I make the fix and continue development.
--
And yes ticket:356 "silent contract on streams" is pretty bad. About 100 X worse than deprecating the old for-statement (ticket:8). Contracts throw exceptions when their conditions are not met. So when you don't get that exception, you know the conditions were met and now you're reasoning about a bug with false information. You can waste a lot of time in that way and I did.
--
You asked about throughput of patch applications, which is a fair question. I have been hoping for some time that by (1) reducing the addition of new features, (2) not implementing pet projects and (3) focusing on fixes that are showstoppers during app development... that the showstoppers would go away.
To some extent they have. I did a web app recently and ran into 3 problems which is fewer than I have run into on previous projects that had less code.
--
@nerdzero: I don't see how a megapatch would fix your issue with testify. And yes patches are more work than they would seem upfront. And no, I don't think one unified patch will be helpful.
--
Going forward, I will budget time in my week, every week (sans vacation or illness), to look at patches. ticket:34 is now in.