[Top][All Lists]

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

Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and,

From: João Távora
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations
Date: Wed, 2 Jun 2021 19:52:20 +0100

On Wed, Jun 2, 2021 at 7:29 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> Not necessarily: a struct is extra allocation and extra indirection to
> get the string. Also could slow down the hot path (the 'all-completions'
> call).

The extra indirection is the cost of an aref, so a tiny increment
to a constant factor that I beliieve is quite large.  You'd pay that with
the saved IFs alone, I suppose. The allocation is about the same,  since
you're allocating less string properties.  This is just a box, and a string
is already a box.

> Another problem with such structs is it encourages "materializing"
> properties for all completions ahead of time, instead of doing it
> lazily. Or if we put a function in every its optional slot, that would
> be both non-obvious and smell of over-engineering.

Off, no don't do that.  If you want indirection, don't use structs, use eieio
objects (CLOS-likes).  You only use structs where you need fast access to.

Indeed structs really shine when very fast access to very commonly
used properties are is required. But we have only minor hints of
these so we'd have to profile.   Structs were just an example, I just
talking about an ADT.

> Now that I understand it better, I say that your proposal is fine (the
> first one in the paragraph above, at least), but I (obviously) don't
> agree that that the current one is as ugly as you paint it.

I don't paint it as particularly ugly (or rather, for me, everything is ugly,
there is only uglier and less ugly). I was just noting an alternative and
looking at its pros and cons.

> It's also
> more in line with the current shape of the c-a-p-f API (have a
> xyz-function return a struct where one of the values if also a function
> is a bit out there).

Are higher-order functions in Elisp APIs really that uncommon? It's the
daily bread in lots of stuff I work on, like capf  for one (maybe that's what
you don't like about it?)  Since lexical binding, they are really really
cool to use in my opinion.  Not gratutiously of course, but for it's
good not to shun them.


reply via email to

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