2 ms·
An architectural adapter. I can't tell you why Swift would "not be suitable" for it as I never claimed that it wasn't. What I did claim is that it is less sui
by mpweiher 6y ago
An architectural adapter.
I can't tell you why Swift would "not be suitable" for it as I never claimed that it wasn't.
What I did claim is that it is less suitable for writing these kinds of adapters between its native architectural style and non-native architectural styles, because it is more restrictive. And being more restrictive is entirely intentional.
And being more restrictive is probably a Good Thing™, overall, in order to prevent silly mistakes, f it weren't for the fact that large parts of the programs we write require, well "strongly request", different architectural styles.
Now if you were actually able to express different architectural styles naturally within the language, you wouldn't need to do so many unsafe metaprogramm-y hackish things.
¯\_(ツ)_/¯
- slver 6y agoWhat you call unsafe hackish things is basically the default level in C. It makes no sense to both call this unwanted in Swift and wanted as a whole language. It comes off as you just don’t like the “unsafe” word.
- mpweiher 6y agoNot sure where you are coming from. If you actually support different architectural styles in the language, like in Objective-S, then you don’t have to resort to the kinds of hackish implementations that were necessary, but at least possible and reasonably easy in Objective-C. And that are still necessary, but much more difficult in Swift, because it (rightly) tries to restrict hackish things, but (wrongly) still doesn’t support other needed architectural styles.
- slver 6y agoI still have no idea what’s the substance here, your example was filters and pipes of cli. That’s trivial in Swift.