carbon-lang

carbon-lang copied to clipboard

I find I am misspelling our adapter keyword as adaptor at least half the time I type it, and I don't seem to be getting better at getting it right. I suspect I won't be the only one who has this problem, and that adapters will be uncommon enough that developers won't, ahem, adapt.

Both spellings are correct in English, and while adapter is the more common spelling by quite a margin in the English-speaking world, it is suggested that

the word adapter is more often used when referring to a person, and adaptor is used when referring to a mechanical device

... and we mean the latter.

Should we do something about this? Some possibilities:

1. Do nothing. Risks generating a small amount of extra work for those of us who spell it "adaptor" in perpetuity.
2. Switch to a different keyword without spelling concerns, such as adapt or newtype.
3. Accept both spellings, and (perhaps) make the formatting tool switch to the "preferred" one.

(Note that I don't think switching to adaptor is really a consideration, despite it being my preferred spelling, because it's clearly the minority spelling.)

As a reminder, here is the alternative considered in #731 :

We considered replacing the adapter keyword with the alternate spelling of "adaptor". Both spellings can be used for the intended meaning, but the "-er" spelling is more common in English text and in code. The final deciding factor was that the GoF Design Patterns book spells the "adapter pattern" with the "-er" spelling.

--

Accept both spellings, and (perhaps) make the formatting tool switch to the "preferred" one.

Making both spellings valid seems like providing two ways of doing the same thing, and would still make trouble for grep and similar... even if formatting tooling fixes it, it's likely developers will commit unformatted code.

Note, in third-party c++ code I can easily search, adapter and adaptor are in almost even use.

Ah yes, we got used to writing in American English. Dialogue and dialog sure caused a few debates.

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.

As far as I'm aware, this question still needs an answer.

Switch to a different keyword without spelling concerns, such as adapt or newtype.

If we can come up with a good different keyword, I'm all for it.

But I don't find any of the current ideas very compelling... adapt doesn't work well for me because the introducer should really identify that the following identifier is the name of a specific new thing being declared. Instead, I expect the next identifier to be an object for the verb.

newtype for me is just too broad of a term, it feels like it should be used in far more places than just here if we allow it.

In the absence of (or until we find) a specific reasonable alternative keyword spelling, I think we should keep the current one. Matching the GoF spelling makes it nicely searchable, etc. It has a lot going for it outside the spelling confusion.

Noting I commented about numbers being close to equal before, one more source search metric using sourcegraph:

• adapter: 41.6M (link)
• adaptor: 4.1M (link)

(i.e., 10x difference in usage in sourcegraph's indexed C++ code)

Noting I commented about numbers being close to equal before, one more source search metric using sourcegraph:

• adapter: 41.6M (link)
• adaptor: 4.1M (link)

(i.e., 10x difference in usage in sourcegraph's indexed C++ code)

We've been writing 'dialog & 'color' & 'initialize' and even 'gray' for colour. Adapter is a pretty well known convention for software. Basically anything Americanised.

So far the best alternative I've been able to come up with is veneer, but that also seems like it'll have spelling challenges.

I think matching the GoF spelling is actually potentially a disadvantage here -- I expect that adapter will be used for "strong typedefs" pervasively, not only in the narrow case that the adapter pattern covers. And in fact our adapter feature does not match the adapter pattern, which is about wrapping one type in another, not providing a different name and functionality for the same representation.

For what it's worth, newtype is taken from Haskell.

I also wonder if we could avoid having a special keyword for this at all, and instead model an adapter as a class with exactly one data member that somehow declares that it's type-pun-able with its data member.

I also wonder if we could avoid having a special keyword for this at all, and instead model an adapter as a class with exactly one data member that somehow declares that it's type-pun-able with its data member.

If we want a change, this seems more promising. Notably, it might let us use the much less ambiguous verb form:

class PlayableSong adapts Song {
  impl as Hashable = Song;
  impl as Media { ... }
}

This reads quite nicely. And we can neatly solve the extending use case leveraging the generalized extends ... discussed syntax:

class Song {
  impl as Hashable { ... }
  impl as Printable { ... }
}

class SongByArtist adapts Song {
  // Extend an already declared and named API.
  extends Song;

  // Add an implementation of a new interface
  impl as Comparable { ... }

  // Replace an existing implementation of an interface
  // with an alternative.
  impl as Hashable { ... }
}

Two issues I see, both might be fixable with slightly different word choice:

• It doesn't seem like syntax adapts Song fits inside the {}s to mark that it is the definition, which is something I quite liked about the generalized extends syntax discussion.
• Related to this, combining these to remove repitition doesn't read well: extends adapts Song;.

But maybe there is a slightly different keyword here that we can use in the same fundamental structure and get a common and generalized pattern of syntax across adapters, bases, mixins, and interface impls.

We've been writing 'dialog & 'color' & 'initialize' and even 'gray' for colour. Adapter is a pretty well known convention for software. Basically anything Americanised.

Just to be clear, not ignoring this. But it also doesn't seem reasonable to look around and see if there is a syntax available that simply doesn't force the tradeoff here.

And I think getting this to be part of a fully regularized class-based syntax has other advantages.

For what it's worth, ISO 14882, which, despite encouraged to use Oxford English spelling, is widely given to American spellings, nonetheless has a subclause spelled "Container adaptors" (and uses that spelling throughout).

Discussed today in open discussion.

In the context of #995, we've been discussing a different syntax: class A { extend adapt B; ... } instead of adapter A extends B { ... }, which would also solve this problem.

In the context of #995, we've been discussing a different syntax: class A { extend adapt B; ... } instead of adapter A extends B { ... }, which would also solve this problem.

As #995 has been decided, should this one be as well and point at #995 for the resolution?

In the context of #995, we've been discussing a different syntax: class A { extend adapt B; ... } instead of adapter A extends B { ... }, which would also solve this problem.

As #995 has been decided, should this one be as well and point at #995 for the resolution?

I don't think #995 addresses adapters directly, but https://github.com/carbon-language/carbon-lang/issues/1159#issuecomment-1504104868 proposes a resolution of this issue that is consistent with the resolution of #995.

In the context of #995, we've been discussing a different syntax: class A { extend adapt B; ... } instead of adapter A extends B { ... }, which would also solve this problem.

As #995 has been decided, should this one be as well and point at #995 for the resolution?

I don't think #995 addresses adapters directly, but #1159 (comment) proposes a resolution of this issue that is consistent with the resolution of #995.

That seems to just be part of the solution, but I see that #995 doesn't really have the whole solution.

Let's outline what a resolution here would look like:

• No new introducer, adapters would use class introducer.

• For non-extending adapters, they would use the following syntax:

  class Song {
    impl as Hashable { ... }
    impl as Printable { ... }
  }
  
  class PlayableSong {
    // Marks this as an adapter for `Song`.
    adapt Song;
  
    impl as Media { ... }
  }
  

  This adapt Song; directive would impose the same constraints as adapters do today: that there are no fields or base classes. If/when mixins are a thing, we'll need to incorporate any restrictions needed there as well.

• For extending adapters, they would use the syntax:

  class Song {
    impl as Hashable { ... }
    impl as Printable { ... }
  }
  
  class SongByArtist {
    // Extend & adapt an already declared and named API.
    extend adapt Song;
  
    // Add an implementation of a new interface
    impl as Comparable { ... }
  
    // Replace an existing implementation of an interface
    // with an alternative.
    impl as Hashable { ... }
  }
  

  Here, the extend adapt Song; directive imposes all the requirements of extending adapters on the class it occurs within.

Does that seem right?

Rationale:

• Match the framework and pattern of these kinds of customization in other parts of the language
• Use the verb forms to avoid spelling difficulties
• Compose with extend where appropriate
• consolidate introducer and forward declaration patterns for class types

As this was pretty heavily discussed already in the context of #995 I'm comfortable saying we have lead consensus here and can move forward. If something about this doesn't look right, this is super easy to revisit in the future.