Re: std.signal : voting results
On Tuesday, 21 January 2014 at 09:26:14 UTC, Dicebot wrote: As an additional comment I wonder if existing signal module should be deprecated and removed completely from Phobos even desite lack of replacement. It sits in the very same niche as this proposal and has even worse implementation with plenty of reported bugs. It becomes hard to justify it at this point. One possibility is a warning about issues and link to the dub package in the docs for std.signal with a hint, that it may be a better choise. Probably same for std.xml. Do we have a package with better xml?
Re: std.signal : voting results
On Wednesday, 22 January 2014 at 23:19:08 UTC, David Nadlinger wrote: This is also the reason why I would have voted no if I made it in time. Documentation and implementation can be fixed later, but we would have had to support a borderline-broken API (with regards to type stringification) for the foreseeable future. The main problem with `std.signal` API is private signals. I think it's important feature, but Robert created additional struct `Signal`, enum `Protection` and string mixin `signal` to implement it. It's only 2 possible solutions: remove private signals or implement new D feature like `friend` keyword. What can we do? Will we create DIP or bugzilla issue? Andrei, what do you think about it?
Re: std.signal : voting results
The new std.signal is IMHO far better than the old one. Why not simply replace it, and then look forward to future improvements?
Re: std.signal : voting results
On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic wrote: The new std.signal is IMHO far better than the old one. Why not simply replace it, and then look forward to future improvements? Guys, were are you was a few days ago when voting still was open?! Dicebot, can we continue voting at least 1-2 weeks? It looks like we finally have interest to the `std.signal` module.
Re: std.signal : voting results
ilya-stromberg píše v St 22. 01. 2014 v 14:38 +: On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic wrote: The new std.signal is IMHO far better than the old one. Why not simply replace it, and then look forward to future improvements? Guys, were are you was a few days ago when voting still was open?! Dicebot, can we continue voting at least 1-2 weeks? It looks like we finally have interest to the `std.signal` module. +1
Re: std.signal : voting results
On Wednesday, 22 January 2014 at 14:38:48 UTC, ilya-stromberg wrote: On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic wrote: The new std.signal is IMHO far better than the old one. Why not simply replace it, and then look forward to future improvements? Guys, were are you was a few days ago when voting still was open?! Dicebot, can we continue voting at least 1-2 weeks? It looks like we finally have interest to the `std.signal` module. No. I am not adjusting procedure post-factum and when evaluating actual results single No vote from Phobos core team (Andrei) outweights few extra Yes votes anyway. We can schedule another review / voting relatively soon though, assuming Robert is still willing to push for it.
Re: std.signal : voting results
Am Wed, 22 Jan 2014 14:18:14 + schrieb Dejan Lekic dejan.le...@gmail.com: The new std.signal is IMHO far better than the old one. Why not simply replace it, and then look forward to future improvements? Phobos has a very strict don't break backwards compatibility rule. IMHO too strict, but that's the way it is. This also means we can't add code if we already know it will have to be modified in not backwards compatible ways in the future. Also the Phobos quality standards must apply to new modules, otherwise those standards are useless. Modules older than these rules and the review process (signals, xml) are (unfortunately) special and I'd just remove those completely, but there can't be any exceptions for new modules. (Thinking of documentation here for example. It's not a problem if a module doesn't pass the review on the first time btw. Just fix the problems and add it to the review queue again)
Re: std.signal : voting results
On Wednesday, 22 January 2014 at 15:44:07 UTC, Johannes Pfau wrote: Phobos has a very strict don't break backwards compatibility rule. IMHO too strict, but that's the way it is. This is also the reason why I would have voted no if I made it in time. Documentation and implementation can be fixed later, but we would have had to support a borderline-broken API (with regards to type stringification) for the foreseeable future. David
Re: std.signal : voting results
On 1/22/14 6:57 AM, Dicebot wrote: We can schedule another review / voting relatively soon though, assuming Robert is still willing to push for it. That would be great, and thanks Robert for being so gracious about it all. Going forward the best way to improve Phobos is to ratchet quality by keeping a high standard. I do understand that can be frustrating since there's stuff _in there_ that is worse off than what's proposed. Andrei
Re: std.signal : voting results
We can schedule another review / voting relatively soon though, assuming Robert is still willing to push for it. Well, I am definitely motivated now that there is some reaction. Although my wife is currently giving birth, so can't really estimate how soon I will get to it, but then I will definitely incorporate the review comments I agree with. There are some I don't agree with or which are not totally clear, I am going to summarize them in a new thread. I hope the people raising them will still be around then. Best regards, Robert
Re: std.signal : voting results
P.S. I really recommend to stop naming relevant dub package `phobosx` and give it own name. You only harm its discoverability that way and spread confusion about its official state.
Re: std.signal : voting results
On 2014-01-21 10:26, Dicebot wrote: It sits in the very same niche as this proposal and has even worse implementation with plenty of reported bugs. If it has plenty of reported bugs someone is/was using it ;) -- /Jacob Carlborg
Re: std.signal : voting results
On Tuesday, 21 January 2014 at 16:51:08 UTC, Jacob Carlborg wrote: On 2014-01-21 10:26, Dicebot wrote: It sits in the very same niche as this proposal and has even worse implementation with plenty of reported bugs. If it has plenty of reported bugs someone is/was using it ;) Or tried to use it and ran away thinking that Phobos quality just laughable. Or wrote a replacement for it which did not pass the review ;)
Re: std.signal : voting results
On 2014-01-21 18:48, Dicebot wrote: Or tried to use it and ran away thinking that Phobos quality just laughable. Or wrote a replacement for it which did not pass the review ;) At least they filed a bug report. -- /Jacob Carlborg
