Open the-plate opened 1 year ago
Since the methods of the interface implementation do not have a pointer receiver shouldn't Stat()
return the struct itself instead of a pointer to the struct?
What implementation do you mean exactly? I can see few having pointer receiver.
https://github.com/studio-b12/gowebdav/blob/master/file.go
I mean the implementation of os.FileInfo
by gowebdav.File
Ok I see.
On one hand, I'm bit confused, the File
struct in file.go
does not implement the mentioned Stat()
function. And on the other hand, it it possible to call value receiver function on a pointer value. The pointer in such case is automatically dereferenced. On top of that the File
implements only, say, getters so the pointer receiver is not necessary and value receiver can be used.
Hello, any comments on this topic ? Thanks!
Hi @ueffel could you please comment on this? Thanks
Ah, I got my trail of thought again:
Returning *gowebdav.File
(pointer to struct) as os.FileInfo
(interface) has an unnecessary level of indirection. Returning a struct (gowebdav.File
) as interface (os.FileInfo
) already makes a pointer out of it.
To align the return types of ReadDir
and Stat
, Stat
should be changed, not ReadDir
:
// Stat returns the file stats for a specified path
func (c *Client) Stat(path string) (os.FileInfo, error) {
- var f *File
+ var f File
parse := func(resp interface{}) error {
r := resp.(*response)
- if p := getProps(r, "200"); p != nil && f == nil {
- f = new(File)
+ if p := getProps(r, "200"); p != nil {
+ f = File{}
f.name = p.Name
f.path = path
f.etag = p.ETag
@chripo thoughts?
I'm think @ueffel is right with the unnecessary level of indirection.
Maybe we should refactor ReadDir
to f = File{}
too?
Yeah, makes sense.
Thanks for comments, will you make the changes?
@the-plate feel free to make changes!
Returns pointer to
os.FileInfo
fromReadDir()
- same as Stat does. This would than ensure compatibility of return types forStat()
andReadDir()
. Now are different.