In other words, perhaps you should be thinking of a way to unify the filesystem API and the FTP API; it seems you've been able to do so relatively well so far, but now you've hit a stopping point: so you should step back and think whether your API for this particular operation is really the best possible API.
If you can't seek FTP files, then why have a seek method in your API? That's specific to open filehandles, so it shouldn't be part of your general API.
As an alternative solution, consider this: maybe your
newmethod, or your
openmethod, should take an argument specifying where in the byte stream the file should be opened. The local-file implementation could then do
to get to the proper spot, and the FTP implementation could doopen FH, ... seek FH, ...
or whatever it is that you need to do for FTP.REST
This approach might be sufficiently general that you won't get into the same problem of an implementation that cannot possibly fit into your API, because your API was not general enough to begin with.
In reply to Re: Polymorphic Abstraction of Disk versus FTP File Access: A Stumbling Block
by btrott
in thread Polymorphic Abstraction of Disk versus FTP File Access: A Stumbling Block
by princepawn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |