search

zoffixznet / IOwesomeness

1 stars 0 forks source link

AP: IO::Handle.seek seek reference #1

Open zoffixznet opened 7 years ago

niner commented 7 years ago

While this proposal makes seek() a bit prettier, I wonder if we shouldn't just go a step further. I don't like the "mutually exclusive named arguments" bit all that much since it lets the user write code which must fail at runtime. Why not just get it over with and have 3 different methods? seek-from-start(), seek-from-current(), seek-from-end(). The names could maybe bikeshedded as e.g. seek-relative() is shorter and you probably guess just right which one it could be? OTOH seek-from-* is nicely consistent. seek() taking an argument telling it what to do is very probably a remnant of ANSI C only allowing 6 (!) significant characters in an external function name. I don't see a reason to let that restrict us in the language for the next 100 years :)

zoffixznet commented 7 years ago

👍 on using seek-from-start(), seek-from-current(), seek-from-end().

jnthn commented 7 years ago

fwiw, I'm not fond of 3 named arguments where it's an error to combine them; that feels - in terms of helping people produce correct code - a step backwards from the enum. I'm OK with splitting it into further methods; otoh seek is quite rare.

One other thing: make very clear in the documentation and parameter name that the units are bytes.

zoffixznet commented 7 years ago

I may just leave it as is.

I wrote this section before I learned 6.d was additive, so I think the gain here is small, if the original .seek and original enums are still present.