Thanks Monty for the clarification. I think I started going down that
rathole when I was removing macros and tried to replace the actual my_*
files, thinking that was the ultimate way to go. I didn't get very far on
that front, but it wasn't a total loss - in following all of the references
using those files I learned a lot about other parts of the codebase!

Chris

On Mon, Jul 13, 2009 at 8:35 PM, Monty Taylor <[email protected]> wrote:

> Chris Musialek wrote:
> > I've been working through one of the low-hanging fruit tasks, trying to
> > remove and replace some of the macros, and after some time in the mysys/
> > directory cleaning up macros that I found I came to realize that most of
> the
> > macros and even files in the mysys/ dir are all stuff that should
> probably
> > just be replaced by C++ STL. I was wondering, what pieces are still tied
> > into using the mysys/ directory that prevent it from being removed
> entirely?
> > I have some ideas, but I thought I'd leave it to the experts. Would it
> make
> > sense to build a task around that goal?
>
> Yes, you are correct. There is a task in fact -
>
> https://blueprints.edge.launchpad.net/drizzle/+spec/code-cleanup-mysys-replacement
> | http://drizzle.org/wiki/Mysys_replacement
>
> Shrews has been working on this some already, and it's sort of an
> ongoing thing, just because of the spidering of stuff. In any case,
> finding something and making a plan on removing it and using either STL
> constructs or standard POSIX calls is a great idea - just be careful,
> you can easily go down a rathole.
>
> As far as I'm concerned, the entire dir should eventually go away - as
> should mystrings.... it's just about taking it one step at a time.
>
> Monty
>
>
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help   : https://help.launchpad.net/ListHelp

Reply via email to