Write operations should use ReadOnlySpan<T>

[dotnet]

Write operations should use ReadOnlySpan

from iot.

[joperezr]

This makes sense, there is no particular reason why to use Span, so I agree that we should be using ReadOnlySpan for writing as well. I'm marking this up-for-grabs. @arkadiuszwojcik let me know if this is something that you would be interested in fixing.

[JeremyKuhne]

They should also use "buffer" as the term. And single items should be "value". So:

    public abstract class I2cDevice : IDisposable
    {
        protected I2cDevice();

        public abstract I2cConnectionSettings ConnectionSettings { get; }

        public void Dispose();
        public virtual void Dispose(bool disposing);
        public abstract void Read(Span<byte> buffer);
        public abstract byte ReadByte();
        // OLD: public abstract void Write(Span<byte> data);
        public abstract void Write(ReadOnlySpan<byte> buffer);
        // OLD: public abstract void WriteByte(byte data);
        public abstract void WriteByte(byte value);
    }

See https://apisof.net/ to find existing patterns. https://apisof.net/catalog/System.IO.Stream.WriteByte(Byte) for an example.

[shaggygi]

I had a related discussion with @joperezr about data/buffer during an earlier PR. He might want to chime in on the thinking around naming.

[JeremyKuhne]

Note that I am not the API review process myself, but what I'm pointing out is based on my experience with that process. Which is hopefully going to get us closer than we would be otherwise. 😆

[krwq]

@JeremyKuhne I've sent PR with the fix but did not include any naming changes

We should re-iterate on all of the APIs at one point separately

[joperezr]

I didn't know that we had an existing pattern for Write where we also called it buffer. What @shaggygi and I discussed in the past, was that it made sense for reading for it to be a buffer since that is where the API will be writing into, but thought that for writing it wasn't really a buffer you fill, but instead just data that you write which is why we had it like that. If we have an existing pattern in the framework, then we should use that instead.