Win: add Crystal::System::DirHandle

[txe]

Moved platform specific things from Dir to Crystal::System::DirHandle
You can find winapi.cr and winerror in this PR #4832

[oprypin]

Alright, so in the other PR it is decided to keep Errno as is for now, so this does not need to be discussed (though it's painful to look at).

How are we feeling about efficiency of these abstractions? A class wrapping a class that ultimately just stores a pointer doesn't seem right.

[bew]

Not exactly related to this pr, but why does ˋmkdirˋ & ˋrmdirˋ returns ˋ0ˋ?

[txe]

I don't know, but in spec there is
Dir.mkdir(path, 0o700).should eq(0)

[bcardiff]

Probably they should be marked as : Nil for avoid leaking a useless return value

[txe]

I'll make another PR for it

[txe]

I suppose, DirHandle cannot be a struct because it has a state. How about to make
class Dir < Crystal::System::DirHandle?

[oprypin]

No no no, a subclass cannot work, that'll leak to documentation and other such details.

You're saying it cannot be a struct (perhaps only ideologically, because technically mutable structs are fine) but I think for these internal objects we have to make an exception and think about them as an inherent part of the public objects. Make it a struct to keep efficiency at a sane level.

Though I just argued in IRC that we could easily do without Crystal::System namespace and keep the separation by files just as it is right now by reopening the types, then we wouldn't even need to discuss this.

[asterite]

Why can't the methods that change between operating systems be implemented directly in Dir without the need of introducing another type?

[oprypin]

@asterite I totally agree with you, but having the Crystal::System namespace was an important decision of the core team that @txe is correctly following. May be worth discussing separately?

---

UPDATE: Discuss Crystal::System in #4906

[txe]

It was suggested to move platform specific code in System, #4406.
@RX14 proposed how to do it for Dir here

[RX14]

Yes, Crystal::System looks silly here, but there are plenty of places where it doesn't look silly and it's already in use. I think we should do it this way for consistency. Explaining 2 or 3 different ways we handle platform specific code to new contributors (or even just people who want to read the stdlib) probably isn't the best of ideas.

[straight-shoota]

This now superseeded by #5447

[RX14]

#5447 was merged, closing this