Re: _wstat on Windows (actually stat stuff in general)

The problem is that stat is API from the 1970's. None of us really
So is malloc. So is chmod. They are wrapped.

want to prolong the life of code with such readable names as S_IFMT,
S_IFREG, st_blksize and EBADF. One of GIO's design goals was to come
up with a fully portable, modern abstraction on top of all this. I for
And if your application can benefit from that, please, by all means go ahead and USE it! But why should that be used as a precluder for someone who wants to USE the smaller, more efficient, working since the 1970's API? A USEFUL tool provides choices. That's what I want to do - provide a choice. I don't want to use GIO thank you very much. Pull in a library with 173762 lines of code (aside from GObject which it depends on)) so I can use G_FILE_ATTRIBUTE_TIME_ACCESS instead of buf.st_atime? No thanks.

GLib is a 21st century platform library, not a pile of portability
hacks. I admit that for convenience it's managed to acquire a bunch of
portability hacks, but this isn't a design goal. If you would like to
I want to add one more portability hack. It serves a need and doesn't impact anyone who isn't interested in using it. I am trying to improve Glib. Not GIO, but Glib. I want to use GLib. Not GObject and libFFI, not Gthread, not GIO. GLib. It has its own headers and its own library. There is one function I want to make more portable, and 2 I want to add because they are missing (seek and tell). If the way you develop software allows you to bring in hundreds of thousands of lines of code rather than using a single structure, then please, be my guest and do so. But please for the love of all that's holy stop trying to tell me that's how *I* should be doing things.

use GIO but find measurable performance problems or missing
1,155,072 jx10-gio2.dll - 'nuff said.

I hear people complaining about lack of maintainers all the time. I am trying very hard to participate in the community and add value. As all newcomers to a project do I pick something small that can benefit others as well as scratch a personal itch. That's how a development community grows. Whether you realize it or not you guys are being down-right contributor hostile. I have absolutely *NO* problem making my own changes to glib and maintaining them for my own purposes. I can use my time writing software instead of debating things with you. But if you want help, and you want fresh blood and you want a developer who is trying desperately to maintain the software on the worlds most common platform and offer precious cycles to your team, then please consider that not every single change has to appeal to one audience, that there are multiple uses of GLib far divorced from the GNOME community or UNIX and that not everyone thinks as you do or uses the software the way you do.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]