A question about naming when implementing interfaces

Brainstorming
1

Hi.

I have re-read (almost) everything what I read before about implementing
interfaces in Zig. Take, for instance, Writer example from this blogpost:

const Writer = struct {
  ptr: *anyopaque,
  ...

As follows from explanations (and also from the stdlib sources), ptr is a pointer to an implementor of an interface. And the Writer is an interface as such.

With these thought in my mind, I would rename some things as follows:

const WriterInterface = struct {
  implementor: *anyopaque,
  // 'ptr' does mean nothing while this name does

As Zig ain’t going to introduce “interfaces/traits/typeclasses” support at syntax level,
maybe it would be reasonable to introduce some conventions about naming structs which are represent interfaces and also about fields in such structs instead?

// Just wonder what people think about that.

2

I see your point and think it’s a valid one, but I also think that programmer laziness will make them gravitate towards typing less whenever they can.

3

Ok, for the moment I am extremely lazy programmer and I’m wrtng this:

cnst WrtIfce = strct {
  implmnt: *anopq,

Which one of these two “spelling” would you prefer? :grin:

1 Like
4

I think that there’s already a convention among many programming languages when it comes to interface names, making them verbs or actions like Writer, Reader, Iterator. I’ve also seen a few languages use the abreviation Impl whtn it comes to implementations, so maybe this is a happy middle ground:

const Writer = struct {
    impl: *anyopaque,
};
2 Likes
5

Readability (and more generally, expressiveness) is a really interesting question actually. It’s highly subjective. For instance, take euler’s formula e^(i * pi) = -1. Is this “readable” or “expressive”? Looks simple enough until you realize it unpacks into sin and cos with the square root of a negative number. IMO, the best we can really call this is “elegant” because it’s rigorous and says what it means in very few symbols.

There’s actually a point where making names longer can reduce readability. For example - say you have a function that dispatches based on several comptime parameters and each of those are a type. That can actually cause the call site to be really long left-to-right or warrant being broken up into multiple newlines. Finally, when you get to the closing parenthesis, there’s often this resounding sense of “what did I just read?”

In general, I find that if it saves you one character to type (like abbreviating month to mnth) doesn’t actually help. In the case of the word Interface, shortening it to Int is just begging for trouble because of the ambiguity it implies.

I think you found an example that lands in the awkward-valley of naming conventions. Again, IMO, the best practice is consistency. I can’t necessarily guarantee that my code will agree with interpretations in general (if that even exists), but at least there’s a pattern within my own code.

2 Likes
6

Yes, impl is pretty good.
If we see that first field has such name we can conclude that the structure itself is interface.

3 Likes