4 ms·
More subtly, passing around objects at all couples the program to the object system — the rules for looking up the objects’ data and behavior is an implic
by look_lookatme 14y ago
More subtly, passing around objects at all couples the program to the object
system — the rules for looking up the objects’ data and behavior is an
implicit global context. If the modules communicate by passing around
self-contained textual data, or a simple structured format like JSON,
then they impose fewer assumptions on each other. Different parts can be
written using different platforms or languages, allowing access to far more
libraries. (They can also be on physically separate computers.)
I may be mis-reading this, but is the author advocating this sort of serialized message passing within local environments, not just between them?
Passing around data bags within local systems seems kinda odd given they have to be deserialized and mapped to a local object anyway. At that point you introduce an overhead of converting objects in the sender context, sending the data bag, converting that message to a an object usable in the receiver context and reverse the process when the method returns.
If you are passing around literal values in strings, then this doesn't matter, but if you are passing around JSON in strings, you end up with a general container that probably has to be inspected and categorized which seems contrary to the whole point of the article.
This is like an American company opening offices in multiple foreign countries and then requiring english to be the only language that can be spoken in those offices.
- TazeTSchnitzel 14y agoWell, you could simply pass around data that can be round-trip (de)serialisabled to/from JSON, and if you need to send it outside the process, actually do real (de)serialisation.
- silentbicycle 14y agoHi. I'm the author. I'm advocating breaking the system into modules with messaging between them, at a fairly course grain (i.e., between subsystems). Within the modules, do whatever you want, but I'm talking about decomposing a system into a service-oriented architecture, or multiple Erlang processes and applications, or Unix pipes, or whatever you want to call it. (Doing it at too fine a grain leads to lots of CPU churn from excess serialization, of course.) JSON is a decent example of a neutral and lightweight protocol, but it's worth actually thinking long and hard about the shape those messages should take. (I prefer text or binary payloads, but I'm also doing embedded development and a real JSON library costs ROM.) Thinking hard about those interfaces/protocols between the pieces, and keeping them tight, is where the value comes from. (Kind of a quick response because I'm at Clojure/Conj today, sorry if I'm missing part of your point.)
- look_lookatme 14y agoOK then, I misunderstood the paragraph. I took it to mean that you were enforcing a lowest common denominator type system across all calls, regardless of intra or inter system. EDIT Reading further, I guess it was the JSON bit that threw me off. It seems that you'd want to have brokers at the edge of modules or in between them in this case. That's may seem architechty, but the reality is that you aren't coupling a module to any non native type representation. Objects go in, objects come out.
- silentbicycle 14y agoEach node can have its own type system, when it makes sense to do so. The arcs between them just need to agree on how they communicate.