On 17/02/2011 03:14, Andy Dougherty wrote:
On Wed, 16 Feb 2011, Nick Wellnhofer wrote:

Branch nwellnhof/unicode_dynpmcs ready is for final testing. It enables
Unicode filename support for all methods of the OS and File DynPMCs. For now
Unicode filenames only work on Linux and Win32, but for other platforms it's
simply a matter of implementing Parrot_init_platform_encoding in
src/platform/*/encoding.c.

I know I've said this before and gotten no response, but this really
strikes me as the wrong way to organize this.  Things like this should
probably be organzied by features, not by platform.  Phrased differently,
how many nearly-identical versions of this file will there be?  Will
Darwin, FreeBSD, MirBSD, NetBSD, OpenBSD, and Solaris all really get their
own independent copies of this file, even though they will all be nearly
identical? As an example of how this gets out of hand, look at the subtly
different versions of env.c.  There was a time when I tried to keep them
in sync, but I gave up.  People changed one but not the other, leading to
subtle breakage.

Instead, I think a single file with judicious #ifdef's is likely to be
easier to maintain (or perhaps 2 files, since Windows is likely to be
rather different).  As an example of this approach, look how I was able to
collapse nearly all of the different sysmem.c implementations.  This also
has the advantage that if a new operating system comes along (e.g.
DragonflyBSD) it will just work out of the box without having to create
another nearly-identical copy of encoding.c.

I completely agree. When I moved the platform code from config/ to src/, I simply kept the existing structure.

We already have a generic/ directory where we can use a single file for multiple platforms. Some of the code should definitely be merged into a single generic file with ifdefs. I did that for the Windows and UNIX socket code already. solaris/time.c is another good example.

encoding.c might be one of the few cases where different files for different platforms make sense, but there probably should be a single file for the BSDs.

Nick
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Reply via email to