In the "Fundamentals"[1] course they use a table format for the design recipe that makes the correspondence between data and functions more obvious, and perhaps the JSP inspiration more evident.
The techniques are not mutually exclusive, it depends on the context.
When you don't have a clear idea of the requirements starting "front to back" helps to understand and gather them while building something that validates them.
For your example "back to front" sounds like a better fit.
It's similar to how pub/sub works but it does the topological sort that prevents data with diamond shaped dependencies from being triggered twice, in less than 500bytes minified (before zipping).
There are tests to validate IE support. The intent is clearly there. Circumstantially this design decision is not met, but it is clearly a bug not some fundamental lack of support.
Please consider how your feedback might affect the people giving their effort to offer an option to the community.
Sorry @taeric, I can't reply to your post directly.
I do think that the intent of the producer is being communicated (unsafe to upgrade, safe to upgrade with new features, safe + automatic improvements).
I'm not disagreeing that "spec" adding more metadata to have better granularity and potentially reducing the amount of manual work is a good thing. But in the absence of it, "semantic versioning" is an improvement over safe and unsafe versions being indistinguishable.
I don't know about maven, but in NPM you can keep both. If you take away the limits of a particular implementation, I think that semantic versioning is a useful convention for the producer of an artifact to convey intent to the consumers.
Wouldn't changing the MAJOR version be equivalent to changing the namespace without altering the human memorable identifier of the package?
Understanding that changes in MINOR.PATCH are backwards compatible, is the difference between NAME MAJOR.MINOR.PATCH and NEW_NAME MINOR.PATCH significant? They look to me as just two different conventions.
I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
I got the impression that the issue was maven not being able to handle multiple versions of the same package/artifact, not in the convention.
I think that contrasting OOP with FP brings too many implicit assumptions to the discussion.
The value of immutability, for example, seems to be orthogonal to the technique used to structure a computation and is more closely related to the problem to be solved.
In my opinion OO languages popularized the idea of having separate internal and external representations by providing language constructs that made it practical. But they also promoted the coupling of data with the methods to manipulate it -- this is not a necessary characteristic of OO but it is common in popular implementations. This association of data and methods turned out to be a limiting factor in the face of changing (maybe unknown) requirements. The flexibility of more dynamic run-times that allow to mutate this relationship during execution (monkey patching) was not a satisfactory solution as it inhibits static analysis. In my experience this is generally the main motivation when looking into alternatives.
Modeling computations as dynamic data threaded through a series of statically defined transformation seems like a sensible solution to the issue. It also brings additional benefits (e.g.: easier unit testing) and makes some constructs unnecessary (e.g.: implementation inheritance). This approach is commonly used in FP languages and I think is the main reason why they are contrasted as alternatives.
Since it's not always possible or desirable to re-write a project, sometimes the technique is dismissed because it is confused with the languages that favor it. The relative lack of resources explaining how to use FP techniques in OO languages doesn't help either.
Separating the techniques from the implementations has practical value and it allows evolving existing bodies of work.
> which isn't really possible if you're rendering html in the server.
You can have a front-end web server that is also a client of the API server and keep the separation as if it were any other API client. This is the approach I'm taking in my current project since I have to support some obsolete browsers, but more generally it lends itself to a cleaner decoupled architecture