Giter VIP home page Giter VIP logo

Comments (6)

rcoreilly avatar rcoreilly commented on June 1, 2024 1

Here's an example:

func (ts *Tensor) SizeTry() ([]int64, error) {
...
}

func (ts *Tensor) Size() []int64 {
...
}

So, as a user, if you think you might have some kind of error, you use the Try version, and check the err, but otherwise use the "plain" version.

Also, the main reason we needed to have two different versions (non-Try and Try) for the GoKi case was when accessing elements in tree structures that needed to then be type-cast into their proper type. This also extends to cases where you want to use the return value directly in expressions of any sort. So, for cases where the return value would typically only be used as an initializer, and not enter into any kind of expression, then I would recommend just going with the Go convention of returning the additional error value, which can be easily ignored in initializers. I don't know how many cases that might apply to here.

from gotch.

sugarme avatar sugarme commented on June 1, 2024

Thanks @rcoreilly for the suggestion. Actually, I was struggling with such naming and still. I chose prefix Must for 2 things:

  1. It reminds keep in mind that our program will panic if error (Idiomatic Go has famous thing of error handling here, not sure whether it is good or bad).
  2. Keep API name similar to Libtorch C++ APIs as much as possible so that when some issues occurs it easy for us to cross-referencing.

I am not sure about the "convention" you mentioned above. Can you elaborate more? I took Must concept from Go standard library regexp.

Anyway, I leave it open as you have a valid point on API consumer point of view there until we have further concrete idea.

from gotch.

rcoreilly avatar rcoreilly commented on June 1, 2024

Here's a bit more explanation of the logic: https://github.com/goki/ki/wiki/Naming

If you need a solid "Go" motivation: the single strongest feature of Go is simplicity, and the standard naming conventions are part of that: keeping names as short and clear as possible. If you add "Must" to every single name, then it kind of loses its value I think, and it becomes a source of visual distraction in the code. Maybe just try rewriting some of your example code and look at the difference. I bet it looks a lot cleaner and simpler without "Must" everywhere.

The Regexp case is a bit different because initializing a regexp is usually fairly rare, so it doesn't have much impact on the code overall. But the reason I wrote this issue is just from a quick glance at the README.md, all the "Must" just jumped out at me! "too Musty" :)

from gotch.

sugarme avatar sugarme commented on June 1, 2024

Yeah, quite "musty" :). However, some may argue that the better way of using APIs is return "error" instead of "panic" so that you have a chance to handle error. If you try gotch with GopherNote you will see that you need to handle error instead of let's it panic otherwise Go kernel will die right away.
Back to your suggestion of using suffix, can you please give me a concrete example? Thanks.

from gotch.

yam8511 avatar yam8511 commented on June 1, 2024

In my opinion, Must is common and familiar for the gopher community.
For example, there're many Must prefix naming function in a lot of golang native library and third-party package.
Official Naming Suggestion

Finally, this is just my opinion. 😃

from gotch.

sugarme avatar sugarme commented on June 1, 2024

close for now as happy with prefix Must APIs.

from gotch.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.