[Top][All Lists]

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


From: Stefan Monnier
Date: Wed, 13 Feb 2008 10:33:23 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux)

> Something like this code:

>          (setq result (cons 
>                        (let ((str (make-string 1 0)))
>                          (aset str 0 (make-char 'japanese-jisx0208 ku ten))

That's truly horrendous code.  I see no reason to support it.

> although it's easy to fix it...

Not only it's easy but the result is more efficient/legible/maintainable.

>> aset on strings is fundamentally problematic, so anything that restricts
>> it further is good in my book (my own local Emacs disallows them
>> plainly, and I rarely bump into code that needs it).

> What is the fundamental problem?

The one you're bumping into: multibyte strings are not arrays and
treating them like ones asks for trouble: the performance is not the one
expected, the implementation is complex and ugly, ...

When weighed against the *very* rare cases where aset is used (let
alone the even more rare cases where aset is actually useful and
convenient), the choice is trivial (for me anyway).


PS: I see bindat.el uses string-make-unibyte is a similar way to the
    place where we recently switched to unibyte-string, except that th
    source is an array rather than a list, and I was thinking: wouldn't
    it make sense to allow `apply' to take an array of args rather than
    a list of args?  Especially if it's of the form (apply FUN ARRAY)
    since we then could use ARRAY directly without having to copy the args
    one by one into a new C array.

reply via email to

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