On Mon, Sep 16, 2019 at 8:39 AM Koichiro Iwao <m...@freebsd.org> wrote: > > On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote: > > The issue is that FLAVORS has added a substantial (and painful) complexity > > to python ports and python.mk. It means that a number of people have had to > > be hyper-vigilant and watch commits closely to catch errors introduced when > > people utilize the paradigm incorrectly. It’s a bitter pill, but it’s > > accepted because the use-case for multiple concurrent python versions is > > essential. > > > > As Antoine said, inconsistency isn’t a strong enough use case. Which brings > > us back to the original question: is there a specific use-case for > > concurrent ruby that makes the substantial increase in cognitive load, > > complexity, and monitoring worth it? > > PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versions > is essential?
We're going in circles here. I've for the third time now that what we'd need to get on board is a use case, a description of the end-user problem that we're trying to solve. What you've provided (for the fourth time in this thread) is a straw man argument. What other languages have is irrelevant. We are much less concerned with "consistency" than with solving end-user problems in a way that fits the specific use case. Steve seemed interested in the idea. I'd explore it with him, and I hope you are able to make it happen. I'm done here. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org _______________________________________________ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
