5 ms·

>because nobody would write an MVC compiler Model - Input -> output format transformation View - input/output Controller - Drives the model And not much cou

>because nobody would write an MVC compiler Model - Input -> output format transformation View - input/output Controller - Drives the model And not much coupling between them except to pass data back and forth. Sounds like a regular compiler to me.

overgard 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. 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.

overgard 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. 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.