[Biococoa-dev] BCScanner

[John Timmer]

> Because it is needed for the BCDigest class, I started working on the
> BCScanner class. First method I attempted was
> 
> - (BOOL)scanSequence:(BCAbstractSequence*)subSequence
> intoSequence:(BCAbstractSequence **)value.
> 
> Trying to emulate what NSScanner does with a string, I am now using
> BCToolSequenceFinder to find the first occurance of the passed
> sequence. Because the BCScanner is probably going to be called a number
> of times in succession, I am doubting if using the BCToolSequenceFinder
> in this way is the most efficient. Maybe the BCToolSequenceFinder
> should be an ivar of the class? That would probably also be a better
> way to keep track of the scanLocation.
> 
> I committed my first attempt, so have a look and let me know what you
> think.

Koen -

I haven't had a chance to checkout the code you put in, but just a quick
question:  what's the advantage to having a scanner for digests, as opposed
to just having the sequence finder return the array of all site ranges?
Just a gut response, but having one less intervening object would improve
code efficiency and readability, so I'm wondering what having the scanner
would provide.

In no way am I saying we shouldn't eventually create a scanner, mind you,
just wondering about its use in this case.


Incidentally, I've looked over the key method "findSequence" in the sequence
finder, and I think it would be very easy to optimize this in some
significant ways, at the expense of only a little readability.  A few of my
ideas:
We have several "if" conditionals inside tight loops - if we inverted things
and put the conditionals outside the loops (which would cause some code
repetition), we'd cut down on the code inside the loops substantially. I
think we'd have to code 4 separate loops (only 1 of which would be used
during a given method call).

We call to an external method - "compareSymbols" - within the loop.  The
method's very short, so we could either move it inside the loop, or convert
it to a static inline function (which essentially does the same thing).

In that method, we use a "isEqualToSymbol" operator between two objects in
the case where we're looking at a strict comparison.  Since we're only using
singletons for symbols, we could replace this with "==" and cut out the
overhead of function calls.

Any objections to me implementing this?  I may even put some cases in the
test app and do a before/after comparison.

JT


_______________________________________________
This mind intentionally left blank