From: KOSAKI Motohiro Date: 2011-12-25T02:09:18+09:00 Subject: [ruby-core:41800] Re: Best way to separate implementation specific code? 2011/12/24 Luis Lavena : > 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_.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�ry >