I'm not sure what discussing syntax has to do with OOP.
The advantage of OOP for me here is that:
the memory layout and lifetime of my HTTP calls and concurrency constructs is exposed
i can pass in different implementations of GET (with TLS, with or without mocks, etc...) or use a DI framework
i use a pattern that is well understood (factory)
OOP is a paradigm, and within that paradigm certain ideas can be expressed easily. In OOP that is the concept of data coupled to function, polymorphism and inheritance for code reuse, and a wide range of well known patterns (factories, strategy, facade, builder, CQRS, observer, visitor). They often have pretty straight forward mappings to functional programming patterns as well.
Thinking about memory layout and ownership in functional paradigms, as well as runtime behaviour, is much harder than in OOP, at least for me. I can't look at a function and quickly see how much memory it will allocate, nor where data is captured and later on released.
There's no reason you couldn't write
join(http::get("foobar"),
http::get("blabla"));
and skip the factories, for example. That C++ decided to use :: as namespace separator, parentheses as function call operator and ; as statement delimiter is kind of irrelevant. I find it easier to read, you don't, who cares.
I understand that if you are not familiar with C++, the syntax and concepts might be confusing, but we're talking professional development by people who understand their tools. When I talk about factories with someone doing OOP, we build upon a shared understanding of what it means.
I understand that if you are not familiar with C++, the syntax and concepts might be confusing, but we're talking professional development by people who understand their tools
I am familiar with C++. I think I'm attributed in the C++ std in fact - At the very least Bjarne Stroustrup used to link to my C++ GUI library (SmartWin) from his home page. I have barely touched upon it since 2008 though. I checked it up a little bit in 2016, at which point I was amazed by its lambda features, and other "functional features" - All of which are arguably ripoffs from FP. However, C++ gives me a headache, because keeping a reference to a destroyed object yields unpredicted results, dereferencing a deleted pointer results in (God knows what), and it's got way too much complexity to do even the simplest of things.
I have the same relationship to C++ (and OOP in general) as I do to having brain surgery. I'll do it if I have to, but I'll do everything I can to avoid needing it ...
Memory ownership is at this point a reasonably well solved problem. You can use unique_ptr or the plethora of other smart pointers. As for c++ having anonymous functions, that indeed cuts down on boilerplate. There's a discussion to be had on how much modern c++ and the STL really are "OOP". I personally don't use the STL and stick with a more traditional "struct with methods" approach, leveraging the template system to strongly enforce invariants at compile time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not sure what discussing syntax has to do with OOP.
The advantage of OOP for me here is that:
OOP is a paradigm, and within that paradigm certain ideas can be expressed easily. In OOP that is the concept of data coupled to function, polymorphism and inheritance for code reuse, and a wide range of well known patterns (factories, strategy, facade, builder, CQRS, observer, visitor). They often have pretty straight forward mappings to functional programming patterns as well.
Thinking about memory layout and ownership in functional paradigms, as well as runtime behaviour, is much harder than in OOP, at least for me. I can't look at a function and quickly see how much memory it will allocate, nor where data is captured and later on released.
There's no reason you couldn't write
and skip the factories, for example. That C++ decided to use
::as namespace separator, parentheses as function call operator and ; as statement delimiter is kind of irrelevant. I find it easier to read, you don't, who cares.I understand that if you are not familiar with C++, the syntax and concepts might be confusing, but we're talking professional development by people who understand their tools. When I talk about factories with someone doing OOP, we build upon a shared understanding of what it means.
I am familiar with C++. I think I'm attributed in the C++ std in fact - At the very least Bjarne Stroustrup used to link to my C++ GUI library (SmartWin) from his home page. I have barely touched upon it since 2008 though. I checked it up a little bit in 2016, at which point I was amazed by its lambda features, and other "functional features" - All of which are arguably ripoffs from FP. However, C++ gives me a headache, because keeping a reference to a destroyed object yields unpredicted results, dereferencing a deleted pointer results in (God knows what), and it's got way too much complexity to do even the simplest of things.
I have the same relationship to C++ (and OOP in general) as I do to having brain surgery. I'll do it if I have to, but I'll do everything I can to avoid needing it ...
Memory ownership is at this point a reasonably well solved problem. You can use unique_ptr or the plethora of other smart pointers. As for c++ having anonymous functions, that indeed cuts down on boilerplate. There's a discussion to be had on how much modern c++ and the STL really are "OOP". I personally don't use the STL and stick with a more traditional "struct with methods" approach, leveraging the template system to strongly enforce invariants at compile time.