[ruby-core:41800] Re: Best way to separate implementation specific code?

2011/12/24 Luis Lavena <[e-mail]>:
> Hello,
>
> As proposed by [ruby-core:38940], I want to move certain functions
> from general file.c into platform specific files.
>
> The idea is make more easy to implement complete function for the
> platform without #fidef/#endif blocks that affect code readability.
>
> When I wanted to implement win32/file.c, noticed that Ruby does not
> build object files in subdirectories, so file.o will clash with file.o
> from the root.
>
> So, need to make win32/win32_file.c
>
> Will that be acceptable?
>
> I noticed that threading implementations are named thread_pthread.c
> and thread_win32.c
>
> What would be the name of POSIX/UNIX implementation for file.c? file_unix=
.c?
>
> Questions:
>
> 1) Should files be named original_<platform>.c ?
> E.g.: file_win32.c, file_unix.c, dir_win32.c

I don't think so. win32/file.c should be allowed. we haven't implemented
such makefile rule, but not refuse to enhance it.


> 2) Should win32 files be placed in win32?

I think so.

> What about thread_win32.c
> which doesn't follow the rule?

Difficult question. As far as I know, it is only historical reason.
thread_win32.c was YARV related code and other don't.


> 3) Should I move exiting POSIX version function to these _unix files?

I don't like to make thousand *_unix.c file. but I agree file and dir have
many different semantics between unix and windows. so, at least, I agree
file_unix.c and dir_unix.c seems cleaner way.


But all of them are only my personal opnion. I'll wait other
developers response. :)


> 4) Should a new section in configure.in to deal with these new
> AC_LIBOBJ additions be added?
>
> There is one already at line 2574.
>
> Thank you in advance for your responses.
> --
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exup=E9ry
>