Naming convention for accessor functions?

[Randall O'Reilly]

I’m trying to figure out the best convention for the basic function of accessing elements in a container (specifically in the context of GUI elements in the case of GoGi / GoKi https://github.com/goki/gi, and also in our new biological neural network simulator in Go: https://github.com/emer/emergent).

The key issue is that we have containers that return an interface, which the user then needs to convert into a particular type. If you have multiple return values from the accessor, then you cannot do this conversion directly in one line. Sometimes you know your access will succeed, and other times you don’t — if you’re unsure, you’ll be checking for failure anyway..

So, first of all, it seems like we need two methods, one with a single return value of the interface, and another with two return values (either an additional error or a bool — there is another question as to which..). The native Go map accessor nicely gives you the option depending on how many variables you give it, but we don’t have that luxury with regular methods (Go2 proposal??).

The question is: which method should be the “default” and which should be “marked” with an extra label, and what should that label be?

Option 1: fast, risky version is the default, use “Check / WErr / Safe” (or another better name?) for the safer version that returns an error. E.g., when looking up an element by Name, you might have:

• ThingByName(name string) Thing
• ThingByNameCheck(name string) (Thing, error) // or WErr (“with err”) or Safe or ??

Option 2: opposite:

• ThingByName(name string) (Thing, error)
• KnownThingByName(name string) Thing

I have used option 2 in GoGi / GoKi, and like the label “Known” as capturing the idea that you don’t need an error because you know it will work (although are there even better options?), but I also feel like I use the “Known” case more frequently, and therefore it should be the unmarked default, and provide the affordance for new users that they should generally use that version and do their conversions directly and efficiently, e.g., foo := Container.ThingByName(“foo”).(*Actual).

Thanks for any advice!

- Randy

ps. while I’m emailing, I just setup a google groups email list for anyone using GoGi / GoKi etc: https://groups.google.com/forum/#!forum/goki-gi — I’m planning to do a lot of work soon getting the 3D part of it working finally, and will email updates there — will be a fair bit of disruption for a while, though the 2D API should remain largely stable (also modulo the outcome if this discussion..)

[Louki Sumirniy]

In the regexp and several other stdlibs they have the qualifier 'Must' for forms that will panic instead of give back an error. I think this might be more like what you need for this case. The Must versions are usually also used when in other constructions errors would be caught during compilation, but can't be because of the use of dynamic types (interface) or non-go code embedded either in strings or possibly declarations that do not invoke inbuilt checks.

I'm not sure exactly how that fits your case. I looked quite closely at GoKi the other day, as I have the need to work with tree shaped data, and to be honest it didn't suit my specific need, which was to be able to concisely declare a structure for a configuration library. However, similarly, in the purpose-built tree declaration syntax, that I built from []interface{} based list types, it thus mandated an extensive early runtime validation.