Earlier quoted context omitted.
Not relevant to this topic.
I think it's relevant as the linked post states that Mozilla was the single user of the XUL runtime.
> Not relevant to this topic.
Goodbye, Node.js Buffer
101–103 of 103 posts
Re: Goodbye, Node.js Buffer
#102Personally, I believe it's better to keep on using the proven buffer vs some person's package. We don't need another left-pad. Also another reason to use a strongly typed language. You call a function that returns a buffer. The interfaces changes and you now get a UInt8Array. You will never know.
Is that what he is suggesting? I thought the article just wanted people to use UInt8Array instead of buffer.
Re: Goodbye, Node.js Buffer
#103Earlier quoted context omitted.
The term "proprietary" does not always refer to software licenses, but that's one of the common causes of something to be proprietary.
How would you define it? The wiki article for it in the context of software ( https://en.wikipedia.org/wiki/Proprietary_software ) seems to pretty much stand it in opposition to open licenses, but I also have a sort of gut feeling that it could also refer to interfaces in OSS that are not designed to re-implementable. Not sure about that though.
It depends on the context I guess.
In the context of not software licensing, I would define it roughly like you said. Interfaces that are designed in a way that is not compatible with existing software or easily implemented by others.
An example would be QT, the GUI framework for C++. It has it's own implementation of stuff that already exists in the standard library, like the string container for example (std::string). You can't use standard C++ types with QT and you can't use QT types with non-QT C++ libraries or types.
I am not a C++ or QT expert so there may be some level of compatibility between the types when using generics or in general, but from my very tiny use of QT it seemed like you had to use their types.