3 ms·

You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how th

You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. Just looking at what you said though: why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Also, claiming the view as input/output is pretty reductive. How do I represent a lexer as a view? More importantly, why would I want to? Fun experiment, find the views and controllers in here: https://github.com/llvm-mirror/clang https://github.com/llvm-mirror/clang

Arnavion 11y ago
>You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. shrug MVC / MVVM is that simple. >why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Models are not limited to being data stores. Models are responsible for doing work, so-called business logic. Controllers / ViewModels work with Views to take in user input and apply it to the models, then take the updated model and give it back to the user. >How do I represent a lexer as a view? The lexer is part of the model. The view would be what the compiler uses for input/output: for a CLI compiler it would be the function that reads stdin or the filesystem + the function that writes to stdout and the filesystem, for a compiler hosted in an IDE or webpage would be the compiler library interface (ie: a programmatic way to give it files or strings and receive output + errors), and so on. Separate views that only know how to take in user input and display user output, interfacing with a common controller/viewmodel + model. Edit: Minor clarifications.
- Arnavion 11y ago
  To clarify, an example of a non-MVC compiler would be something that expects to read a list of files from argv and expects to write to stdout. An example of a MVC compiler would be something that abstracts the act of compiling bytes into bytes from how it obtains those bytes or puts them out. I think gcc works like the former and clang like the latter? I'm not familiar with either. An example I am familiar with is the TypeScript transpiler - a "Compiler" class with a pluggable "Host" interface. There is one implementation of that host for each environment it can run in (in-memory, node.js, cscript.exe) that knows how to read files and write output. The compiler class would call host.writeFile(filename, contents) and it's up to the host whether to write that to a file, or a textarea in a web page, or pipe the string to another transpiler, or whatever. It's up to the view to decide whether to colorize output or not, whether to show an underline that the user can click to jump to the error or not, etc. Basically the view is independent of the model, and provides functionality local only to its interaction context that the model shouldn't need to care about. As a bonus it's pluggable and thus easy to write new views.
  - jerf 11y ago
    If your model fits everything, it fits nothing. If you've stretched until compilers are "MVC", you haven't got MVC anymore. Something has to be meaningfully a good design that is not MVC for MVC to exist as a distinct solution. MVC is not simply "things should be abstracted from each other". That just, well, abstraction. (Or, better, indirected: http://zedshaw.com/archive/indirection-is-not-abstraction/ http://zedshaw.com/archive/indirection-is-not-abstraction/ ) I've been anti-MVC (unless you are in the rare situations where it really works) for a while, and this is precisely why. It clouds people's thought. It convinces people they're doing "design" when they are often just complexifying things by rote application of badly misunderstood ideas.
    - Arnavion 11y ago
      Separation of concerns is neither complexity or misunderstood. It's just good design.
      - jerf 11y ago
        MVC !=== separation of concerns. Separation of concerns is something else. If "MVC is just exactly the same as separation of concerns", then, again, we don't need "MVC" as a concept. We already have "separation of concerns". Again, this is why I find the term loathsome as it is actually used. Not only do people not think about it, they, like, actively won't think about it. Anyone who actually tries to nail down "what exactly is MVC" will find themselves coming up empty. It is an undefined term, and should be discarded for pretty much everybody who isn't writing a CAD/CAM app, not used as some sort of vague template for "all good design". You've progressively shrunk the goalposts in every post in this series until you can't help but hit MVC. That's not useful.
        overgard 11y ago
        To your example, I work on a CAD app that runs on web and even we don't use MVC. :-) (Similar concepts, sure, but no buzzwords or worry about being MVVM or whatever)
        11y ago

Arnavion 11y ago

>You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. shrug MVC / MVVM is that simple. >why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Models are not limited to being data stores. Models are responsible for doing work, so-called business logic. Controllers / ViewModels work with Views to take in user input and apply it to the models, then take the updated model and give it back to the user. >How do I represent a lexer as a view? The lexer is part of the model. The view would be what the compiler uses for input/output: for a CLI compiler it would be the function that reads stdin or the filesystem + the function that writes to stdout and the filesystem, for a compiler hosted in an IDE or webpage would be the compiler library interface (ie: a programmatic way to give it files or strings and receive output + errors), and so on. Separate views that only know how to take in user input and display user output, interfacing with a common controller/viewmodel + model. Edit: Minor clarifications.

Arnavion 11y ago
To clarify, an example of a non-MVC compiler would be something that expects to read a list of files from argv and expects to write to stdout. An example of a MVC compiler would be something that abstracts the act of compiling bytes into bytes from how it obtains those bytes or puts them out. I think gcc works like the former and clang like the latter? I'm not familiar with either. An example I am familiar with is the TypeScript transpiler - a "Compiler" class with a pluggable "Host" interface. There is one implementation of that host for each environment it can run in (in-memory, node.js, cscript.exe) that knows how to read files and write output. The compiler class would call host.writeFile(filename, contents) and it's up to the host whether to write that to a file, or a textarea in a web page, or pipe the string to another transpiler, or whatever. It's up to the view to decide whether to colorize output or not, whether to show an underline that the user can click to jump to the error or not, etc. Basically the view is independent of the model, and provides functionality local only to its interaction context that the model shouldn't need to care about. As a bonus it's pluggable and thus easy to write new views.
- jerf 11y ago
  If your model fits everything, it fits nothing. If you've stretched until compilers are "MVC", you haven't got MVC anymore. Something has to be meaningfully a good design that is not MVC for MVC to exist as a distinct solution. MVC is not simply "things should be abstracted from each other". That just, well, abstraction. (Or, better, indirected: http://zedshaw.com/archive/indirection-is-not-abstraction/ http://zedshaw.com/archive/indirection-is-not-abstraction/ ) I've been anti-MVC (unless you are in the rare situations where it really works) for a while, and this is precisely why. It clouds people's thought. It convinces people they're doing "design" when they are often just complexifying things by rote application of badly misunderstood ideas.
  - Arnavion 11y ago
    Separation of concerns is neither complexity or misunderstood. It's just good design.
    - jerf 11y ago
      MVC !=== separation of concerns. Separation of concerns is something else. If "MVC is just exactly the same as separation of concerns", then, again, we don't need "MVC" as a concept. We already have "separation of concerns". Again, this is why I find the term loathsome as it is actually used. Not only do people not think about it, they, like, actively won't think about it. Anyone who actually tries to nail down "what exactly is MVC" will find themselves coming up empty. It is an undefined term, and should be discarded for pretty much everybody who isn't writing a CAD/CAM app, not used as some sort of vague template for "all good design". You've progressively shrunk the goalposts in every post in this series until you can't help but hit MVC. That's not useful.
      - overgard 11y ago
        To your example, I work on a CAD app that runs on web and even we don't use MVC. :-) (Similar concepts, sure, but no buzzwords or worry about being MVVM or whatever)
      - 11y ago