W3C home > Mailing lists > Public > www-svg@w3.org > November 2009

Re: Again with the getIntersectionList()

From: G. Wade Johnson <gwadej@anomaly.org>
Date: Fri, 20 Nov 2009 07:32:41 -0600
To: Andreas Neumann <a.neumann@carto.net>
Cc: Jonathan Watt <jwatt@jwatt.org>, Jeff Schiller <codedread@gmail.com>, www-svg <www-svg@w3.org>
Message-ID: <20091120073241.4895bccc@sovvan>
I'm following this discussion with quite a bit of interest, and I only
have one (possibly) useful observation to add.

On Thu, 19 Nov 2009 21:58:16 +0100
Andreas Neumann <a.neumann@carto.net> wrote:

> Hi all,


> >  * Would you really want 'pointer-events' to be taken into account?
> >   
> I think there should be a parameter in the two methods that specify
> the behavior. I think there use-cases for both modes - taking them
> into account or not.


> >  * Would bbox intersection checking be sufficient?
> >   
> Not for all cases. I think there should be a parameter: bounding box 
> checks (faster) and checks on full geometries (slower, but more
> accurate)

From the perspective of decades of code maintenance and development, I
would advise against adding a parameter to select between two modes of
operation in the public interface. It always seems to add to the mental
overhead when dealing with an interface like that.

For the sake of argument, imagine trying to maintain code (even a few
days after you wrote it with a call like:

   elems = getIntersectionList( rect, true, false );

Now is that "use pointer-events" and "only use bounding box" or what.
It may not seem like much effort to look up the flags (one more time)
to see what they mean. But, after maintaining a lot of code, I can say
it does make a difference.

It's a difficult trade-off to decide whether to make the interface
larger by adding more methods, but it's worth the consideration.

G. Wade
If a cluttered desk is the sign of a cluttered mind, what is the
significance of a clean desk?                   -- Laurence J. Peter
Received on Friday, 20 November 2009 13:33:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:24 UTC