Front page | perl.perl5.porters |
Postings from June 2006
On 6/25/06, Nicholas Clark <nick@ccl4.org> wrote: > On Tue, Jun 20, 2006 at 08:32:11AM +0200, demerphq wrote: > > > Yes, core perl support for Win32 is much less than what it should be, > > which in turn means all the linux programmers who dont have a clue > > about how windows work[1] end up just coding as tho their code will > > run on *nix regardless, and therefore their code doesnt work when it > > gets run on Win32. > > Linux programmers who don't have a clue write code that doesn't even > work on real Unix. Heh. Ok, i dont feel so bad now. :-) > > The solution to this problem is to improve core support for OS > > abstraction. Something ive been advocating and sending patches in for > > No, I'm not convinced that it is. Surely down this road lies lowest common > denominator? How does this differ from cross-platform GUI toolkits, which > seem to generate quite a lot of comments about how they don't have the > look-and-feel of native apps, for any given platform. Actually, to a certain extent what im talking about is that *nix is for all intents and purposes the lowest common denominator, and that providing functionality at that level only, which is pretty much what perl does, is not sufficient when dealing with OS'es that have more sophisticated (don't assume this means better by any means) infrastructure. So for instance a lot of unixisms are faked by OS'es like Win32. An example would be file executable status. Whats an executable? On *nixy os'es they are the ones with the executable file attribute set. On win32 its something else. Which leads to weirdness like: d:\>echo print 1 > t.pl d:\>perl -e"print -x 't.pl' ? 1 : 0" 0 d:\>t.pl 1 Another more common example of this is code that completely ignores the fact that on some OS'es files have volume specifications in addition to path specifications. Even code that uses File::Spec tend to assume that the vol part of File::Spec->splitpath() is going to be empty. Other examples are things like how to work with tempfiles, default permissions and sharing attributes when files are opened.... So I think that if you are going to provide an abstaction layer it needs to be designed with the opposite of the lowest common denominator in mind. Where an OS cant provide that functionality the abstraction layer should do what makes sense. If the semantics of 'open' where changed to support more advanced locking and sharing models, in memory temp files, or delete on close semantics then UNIX would just ignore or fake it as needed. But where the additional semantics are supported the os should do so. In fact i once recommended that open be extended to support the idea of opening a self deleting temporary file. On unix this would mean that open would do the unlink logic, on win32 it would do something else. Either way it would mean that programmers wouldnt have to worry about how it happens. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"