* Jim Cromie <[EMAIL PROTECTED]> [2003-11-14 09:35]:
My version has a different focus, namely to find duplicate code
chunks, write macros for them, and invoke those macros. So
maybe a different name is appropriate.
So it is aimed at processing C sources? Then File:: is the wrong
TLNS for it, although off hand I'm at a loss about which one it
should be in. I'm not sure Parse::C:: is fitting here?
Its not 'particular' to C, except in reduce(), the last step, which acts on the detected redundancies.
As I outlined, a Perl version could move chunks into strings, then eval that in the many places
its needed.
Parse::* makes promises about its capabilities / sophistication which are untrue.
I also looked at generating functions for the chunks and calling those where needed, but
that was clearly harder ( taking addys of args in callers, doing derefs in fn body, skipping globals )
I havent entirely given that notion up though..
I think the fact that it compares "shreds" is to be ignored as an implementation detail for the name at least.
Indeed its an implementation thing, but 'Shred' is unlikely to be confused with anything else,
except perhaps 'rm -rf *', which most people wouldnt look on CPAN for ;-)
And because 'shred' is open-source, and part of the Linux vs SCO drama, it serves as something of a touchstone - By understanding the algorithm, you know its advantages/disadvantages; fast but naive compared to parsing to an ASN.
Its also applicable to any line-oriented text, not just programs, hence the File::
While it wont find re-wrapped text (cuz line boundaries have shifted), it will
(once ive nailed the N-file crosscheck) find duplication between *.pm and readme.
Aside: this suggests that an interactive capability to skip chunk reduction would be good.
The fact that it generates macros is important of course.. so is the fact that it does so for common code, though. That should probably be in the name somewhere.
Parse::C::CommonToMacros? Awkward and not truly descriptive I
think..
btw - Macro in the name could imply to some that it can write parametrized macros.
It cant - cuz the md5 fingerprinting foundation doesnt work that way.
For macroizing, the best it can do is 90%, leaving plenty for the hacker to do.
That said, Ive already seen similarities in the generated macros which look parametrizable.
Hmm..thx for your comments.
PS - I havent posted code or pod, it doesnt seem to be the module-authors way..
I can do so (public or private ) if anyone cares to see it at this point.
