[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] CR #1142 and upcoming changes
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] CR #1142 and upcoming changes |
Date: |
Tue, 19 Aug 2014 10:27:02 +0200 |
User-agent: |
Mutt/1.4.2.3i |
On Tue, Aug 19, 2014 at 10:20:56AM +0200, Felix Winkelmann wrote:
> I understand your concerns, but doing all the planned changes piece by
> piece will be a massive maintenance effort and the compatibility hacks
> required to have something halfway working during the transition will
> be even more. I also hate forcing users into upgrading - I always
> detested this in other software and would like to spare those that
> need a working system, for whatever reason.
To avoid doing this again soon, I think the other change you suggested
should definitely be included: the reworking of internal libraries by
splitting them up. Perhaps you already assumed this would be included,
I don't think I have seen this mentioned yet so I wanted to put it out
there.
> I also don't see a reason _not_ to consider adding the features you
> talk about, but it shouldn't be the main driving force. If we can
> provide support for this, fine! But someone has to implement it (of
> course)
>
> So I think: let's just see how well we get along. We should definitely
> look into what would be required for bignum/unicode support, if
> someone is willing to evaluate this.
No problem @ bignums. I don't know much about unicode, so that should
probably be looked at by someone else. A simple thing we could include
would be to reject all strings that have invalid UTF-8 encoding, like
Postgres does that. I always really appreciated this feature of Postgres:
it ensures that you don't get invalid data in your system, and prevents
pollution and getting in "character set hell", like happens all the time
in MySQL:
https://www.bluebox.net/insight/blog-article/getting-out-of-mysql-character-set-hell
Adding rejection of non-UTF-8 strings would make the transition to a
"full" Unicode system less painful (and perhaps make it possible to do
it in a non-breaking way). I'm not sure how difficult this would be,
though: all string mutation procedures should have a check that they
won't create invalid strings by setting characters (bytes).
Cheers,
Peter
--
http://www.more-magic.net
- Re: [Chicken-hackers] CR #1142 and upcoming changes, (continued)
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Felix Winkelmann, 2014/08/19
- Re: [Chicken-hackers] CR #1142 and upcoming changes, John Cowan, 2014/08/19
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Felix Winkelmann, 2014/08/19
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Ivan Raikov, 2014/08/19
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Andy Bennett, 2014/08/20
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Peter Bex, 2014/08/19
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Felix Winkelmann, 2014/08/19
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Felix Winkelmann, 2014/08/19
- Re: [Chicken-hackers] CR #1142 and upcoming changes,
Peter Bex <=
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Felix Winkelmann, 2014/08/19
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Yaroslav Tsarko, 2014/08/20
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Peter Bex, 2014/08/20
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Felix Winkelmann, 2014/08/20
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Alex Shinn, 2014/08/20
- Re: [Chicken-hackers] CR #1142 and upcoming changes, John Cowan, 2014/08/20
- Re: [Chicken-hackers] CR #1142 and upcoming changes, Felix Winkelmann, 2014/08/20
- Re: [Chicken-hackers] CR #1142 and upcoming changes, John Cowan, 2014/08/20
Re: [Chicken-hackers] CR #1142 and upcoming changes, John Cowan, 2014/08/18