5 ms·
> On the other hand a binary-based object-oriented approach can give better performance and make it easier to parse data please, no. OOP approach means that my
by agoodboy 10y ago
> On the other hand a binary-based object-oriented approach can give better performance and make it easier to parse data
please, no. OOP approach means that my process needs to know how to communicate with other processes via very specific protocols, which aren't very well defined (any process could describe its type of object). This is the exact opposite of flexibility. The usefullness of tools like grep or sed would drop drastically, and we would fall back to big blobs of software.
Since I'm just passing data, do I really need the behavior attached to it?
How would state persistence be handled?
The text (bytes as ASCII until line ending) approach may seem ugly and dirty, but in fact you can pass list, tuples, maps, trees or just text and is up to the receiver the responsibility to make sense out of the data.
Need data from A but B can't understand it? Use C (which operate on text) to format A's output as B needs. With object how many "translator" (C in the example) would you need to acheive the same result?
- ZenoArrow 10y ago> "please, no. OOP approach means that my process needs to know how to communicate with other processes via very specific protocols, which aren't very well defined" It's not as hard as you make out. Take a look at how PowerShell works for an idea about how a OOP-based approach can work for CLIs. http://www.computerworld.com/article/2954261/data-center/understanding-and-using-objects-in-powershell.html http://www.computerworld.com/article/2954261/data-center/und...
- Avshalom 10y ago>>process needs to know how to communicate with other processes via very specific protocols >>and is up to the receiver the responsibility to make sense out of the data That is exactly the same thing. Either way you're throwing bytes from one process to another and hoping the second one can do something useful with it.
- zvrba 10y ago> OOP approach means that my process needs to know how to communicate with other processes via very specific protocols, which aren't very well defined (any process could describe its type of object). That's why we have IDL -- interface description language for RPC calls. An IDL-to-X (usually C) compiler generates the necessary glue so that anybody can talk to the program in question. IDL is also the basis of MS COM, which I quite like from the design standpoint. > The usefullness of tools like grep or sed would drop drastically, and we would fall back to big blobs of software. So you teach grep to take an IDL file, invoke an IDL compiler and dynamically load the parser for the protocol in question. Also, if the broker were a standardized, perhaps in-kernel component (dbus, kdbus), you could attach "idlgrep" to any process to trace its calls. You wouldn't be restricted to pipes. > Since I'm just passing data, do I really need the behavior attached to it? How would state persistence be handled? The parent's wording was a bit unfortunate. You can have interfaces and interface inheritance and versioning (the "OOP" part), but there's no behavior send between processes. > With object how many "translator" (C in the example) would you need to acheive the same result? Exactly one: the IDL compiler.
- gaius 10y agoHeh, you will only be able to openly advocate IDL once the last CORBA programmer is dead. We've been down that route. It didn't work.
- majewsky 10y ago> So you teach grep to take an IDL file, invoke an IDL compiler and dynamically load the parser for the protocol in question. Also, if the broker were a standardized, perhaps in-kernel component (dbus, kdbus), you could attach "idlgrep" to any process to trace its calls. So you introduce a huge load of accidental complexity because the text interface has some perceived inefficiency? I'll choose simplicity and accessibility over this mess anytime.