On Friday, 11 May 2012 at 15:05:19 UTC, deadalnix wrote:
Le 11/05/2012 16:02, Roman D. Boiko a écrit :
Technically, I'm trading N*0(1) operations needed to track
line and
column while consuming each character to M*0(log(n))
operations when
calculating them on demand. N = number of characters, n is
number of
lines and M is number of actual usages of Location. My
assumption is
that M << N (M is much smaller than N).
N can easily be number of tokens.
Yes, if you are looking for the token by its index, not for
location. E.g., for autocompletion it is needed to find the last
token before cursor location. But that is not related to location
search.
Also please note that I oversimplified formula for complexity. It
also has other components. My reply was just an additional minor
comment. Motivation is design, not performance.
One additional reason for such separation: with my approach it is
possible to calculate Location both taking into account
infromation from special token sequences, or ignoring it. How
would you do that for eager calculation? Calculate only one
category? Or track and store both?
Unnecessary complexity will eventually find a way to shoot your
leg :) Real-world usage (at least, anticipated scenarios) should
be the basis for designing. Sometimes this contradicts intuition
and requires you to look at the problem from a different side.
