4 ms·
Already exists, e.g. F# in Visual Studio. Note however that type inference and dynamic typing, although similar on the surface in that you don't have to write t
by jules 15y ago
Already exists, e.g. F# in Visual Studio. Note however that type inference and dynamic typing, although similar on the surface in that you don't have to write type annotations, are completely different things.
The OO tenet says "Don't couple unrelated things". The converse of this is "Don't decouple related things", which is equally valid yet often ignored. Decoupling X and Y means that in the cases where you want to use X and Y together you need to connect them together again. This is a bad thing if in 99% of the cases you want to use X and Y together.
An example of this is the Java file API. In an effort to decouple a reference to a file, a reference to a stream of the file's contents, a reference to an arbitrary stream, reading from a stream, and reading from a stream in a buffered way, we end up with FIVE classes (File, FileInputStream, DataInputStream, InputStreamReader, BufferedReader) that will almost always be used together simply to read the contents of a file. This is of course an extreme example. A better design is to "couple" these things together in a gimmeTheContentsAlready(filename).
Likewise, the Opa guys are expecting that most people who use their stuff will use their database interface, and their language on both the server and the client, their easy client/server networking, and their http server. Shipping these as separate components would induce a lot of work to integrate them together again.
- stcredzero 15y agoThe OO tenet says "Don't couple unrelated things". The converse of this is "Don't decouple related things", which is equally valid yet often ignored. Orthogonal areas of concern that are used together are just that: used together. They can be used together and packaged in a way that's super convenient. That still doesn't mean I want them tightly coupled. NB: Works well together != tightly coupled. An example of this is the Java file API. In an effort to decouple a reference to a file...we end up with FIVE classes Yeah, I freakin hate that too. This Java JMI Api I used once, I had to instantiate seven entities from as many different classes just to get to send a message. But not all Java libraries are paragons of good object design. (You can leave off the Java, actually) A better design is to "couple" these things together in a gimmeTheContentsAlready(filename). Sorry, but you're mistaken here. Things are just as decoupled in the VisualWorks Smalltalk class library. There are equivalents to: (File, FileInputStream, DataInputStream, InputStreamReader, BufferedReader) and much more, but you can also still do: 'file.dat' asFilename readStream If you wanted to, you could just add a method to String named gimmeTheContentsAlready that would just return you the whole contents of the file with that pathname as a String. (I'd name it fileContents, though.) Either would take 3 short, easy to read lines of code, or one messy one, and about 2 minutes to write and save in your image. Convenient methods and well designed APIs aren't the same as "tight coupling." If you think they are, then you need to read some better OO code. EDIT: Another example -- at the same place there was a Sun message bus we used in the same product line, same functionality as JMI, just with better performance. Needed to instantiate 2 object to send a message with that.
- jules 15y agoIt just depends on your definition of tightly coupled. By your definition Opa's implementation isn't tightly coupled either (the http server doesn't depend on the database, etc.). A better term is probably tightly integrated, and as far as I can see they also use this term on the rest of the website.
- stcredzero 15y agoIt just depends on your definition of tightly coupled. Back in my day, "tightly coupled" was somewhat like the opposite of "modular."