Implemented Dir.children

[Sija]

Closes #4807

[jhass]

Slight improvement to the spec is possible, looks good otherwise.

[jhass]

How about comparisons comparing the output to Dir.entries here? Like checking that the size is the same minus two and that all returned items are also in the other.

[akzhan]

Example with size - 2 knows about implementation details, and should be not used.

[Sija]

@jhass done.

[RX14]

How about a yielding version?

[Sija]

@RX14 I wouldn't mind but there's no yielding version of Dir.entries so why here?

[ysbaddaden]

It would be nice to interate without allocating HEAP memory. I guess #entries should allow the same.

[Sija]

@ysbaddaden I concur, yet it sounds like a topic for a separate PR.

[RX14]

@Sija Isn't the yielding version of Dir.entries Dir.foreach? I think thats's pretty confusing. But yes, we can leave clearing up the naming to a different PR.

[Sija]

@RX14 IIRC it comes from Ruby, but yeah, I'd say it is a bit confusing. Ruby has Dir.each_child yielding method to complement Dir.foreach btw.

[RX14]

I think it's confusing having different names. We should have entries and each_entry and children and each_child.

[bew]

@RX14 and what should be Dir.each? should we remove it?

[RX14]

What's currently Dir.foreach would become Dir.each_entry.

[Sija]

@RX14 Why not two versions of Dir.entries and Dir.children with yielding and non-yielding overloads?

[RX14]

@Sija Because that's not how we do naming of yielding/collection members. Think of String#chars and String#each_char. There are plenty of other examples.

The reason for the existing convention is that the name is more descriptive: foo.each_char do |char| vs foo.chars do |char|.

[Sija]

@RX14 Fair point, it is more descriptive indeed.