I'm designing a global extension system which makes it possible to add some extensions where-ever you need some extensions. Those extensions may require some other extensions, which may have conflict with other extension requirements; so I'm using this meta-programming magic to solve that issue and only inherit from a unique list of extensions.
The Tweet
The Tweet
Twitter
The Moisrex
This is how you make a unique list of types in C++: static_assert( std::is_same_v< typename typelist<int, int, char, char>::unique, typelist<int, char> > );
Web++: A C++ Web Framework
Somehow these bugs are all over the project for no apparent reasons what so ever 😂
Fixed one of them. Can you spot? 😁
Web++: A C++ Web Framework
Why did I think this was a good idea? Seriously, WHY?
Is it that bad? Any new ideas on what should I do with this?
1. Replace with std::any (Too slow maybe!?)
2. Use extensions (Becomes complicated maybe?)
3. Use inheritance (Don't even think about it!)
4. Use void* + size + extensions (I don't know what I'm talking about 😂)
5. ...???
1. Replace with std::any (Too slow maybe!?)
2. Use extensions (Becomes complicated maybe?)
3. Use inheritance (Don't even think about it!)
4. Use void* + size + extensions (I don't know what I'm talking about 😂)
5. ...???
I'm gonna add extensions to everything; including:
- Protocols
- Interfaces
- Routers
- Requests
- Responses
- Contexts
- Headers
- Bodies
Each extension may require other extensions from the same level, or even lower levels which the type itself has access to at compile time.
This way for example you can add an extension to the router and see the result in the context or even the requests and response.
An example would be cookies which will be added to the headers level but with a little of boiler plates, you can use it as a router level extension.
This is a nice way but I wonder if a unified extension type would be a better solution.
- Protocols
- Interfaces
- Routers
- Requests
- Responses
- Contexts
- Headers
- Bodies
Each extension may require other extensions from the same level, or even lower levels which the type itself has access to at compile time.
This way for example you can add an extension to the router and see the result in the context or even the requests and response.
An example would be cookies which will be added to the headers level but with a little of boiler plates, you can use it as a router level extension.
This is a nice way but I wonder if a unified extension type would be a better solution.
Read this from top to bottom, or bottom to top. Your choice!
Today was the worst day
and don't try to convince me of that
there will be some good moments everyday
if you look carefully,
life is hard
even though
many times good things happen
happiness doesn't exists
and it's not true that
many things depend on us
I'm sure you agree that
the environment that we're in
affects directly on
our behavior
not everything is in our control
and you never see me saying
today was a good day
Today was the worst day
and don't try to convince me of that
there will be some good moments everyday
if you look carefully,
life is hard
even though
many times good things happen
happiness doesn't exists
and it's not true that
many things depend on us
I'm sure you agree that
the environment that we're in
affects directly on
our behavior
not everything is in our control
and you never see me saying
today was a good day
Collaborative Response (Collaborative output):
This is the the way that multiple sub-routes each prepare parts of a response.
For example:
Sub-route 1 will prepare the template (header and body).
Sub-route 2 will prepare for example the dynamic stuff in the page that are still boiler plate (where the user profile picture would go and notification stuff and these kinda stuff)
Sub-route 3 fills a complex table for example
Sub-route 4 fills a the rest of the stuff in the page
Sub-route 5 ...
I haven't seen this idiom anywhere yet. With the new routing system you'll be able to do this in the future as easy as it's possible. You just have to add one extension into your router. That's it.
This is the the way that multiple sub-routes each prepare parts of a response.
For example:
Sub-route 1 will prepare the template (header and body).
Sub-route 2 will prepare for example the dynamic stuff in the page that are still boiler plate (where the user profile picture would go and notification stuff and these kinda stuff)
Sub-route 3 fills a complex table for example
Sub-route 4 fills a the rest of the stuff in the page
Sub-route 5 ...
I haven't seen this idiom anywhere yet. With the new routing system you'll be able to do this in the future as easy as it's possible. You just have to add one extension into your router. That's it.
I think C++20 concepts are great ways to reduce header dependency hierarchy, compile time, and maybe even code bloat; specially for header-only libs.
How? By introducing a concept for every type that the library user needs to use; in a different header file.
This way half of your library is not dependent on the other half of the library; they just need the concept header files of those types not the types themselves.
Of course if you're not using templates, don't use this tricks since introducing templates to the code adds more compile time but if you already doing TMP, then the chances are that with concepts that are not actually checking the exact type, you can reduce header dependency.
Most of the time your library doesn't need to know the actual type, it just needs to know what you can do with that type; which of course leads to more general code.
Of course C++20 modules also can fixes the same problems in most cases but not all of them.
How? By introducing a concept for every type that the library user needs to use; in a different header file.
This way half of your library is not dependent on the other half of the library; they just need the concept header files of those types not the types themselves.
Of course if you're not using templates, don't use this tricks since introducing templates to the code adds more compile time but if you already doing TMP, then the chances are that with concepts that are not actually checking the exact type, you can reduce header dependency.
Most of the time your library doesn't need to know the actual type, it just needs to know what you can do with that type; which of course leads to more general code.
Of course C++20 modules also can fixes the same problems in most cases but not all of them.
After talking with experts (Author
I will also use
std::format and others) on twitter, seems like the best strategy for using {fmt} and boost::asio as fallback, is to use webpp::std namespace instead of ::std.I will also use
webpp::stl for adding features (not as polyfills).Heavy project development stack:
0. Research Driven Development
1. Documentation Driven Development
2. Community Driven Development
3. Test Driven Development
4. Resource Driven Development
5. Time Driven Development
Research Driven Development is when you need to research (learn) a bit, and do that bit, then research a bit, then do that bit, and so on ...
Documentation Driven Development is when you write the detailed documentation of the parts that you need, before actually implementing them in the project.
Not all projects require extensive documentations despite what most people try to tell you; but it's extremely helpful.
Community Driven Development is when the project is as big as its community of developers; sometimes that tasks cannot be handled by one person, so other experts will be included in the community and those experts are the ones that continue their parts of the project.
Test Driven Development is when you write a usage of the project, and then actually go and implement it. Many tools are available for this job.
Resource Driven Development is when you can only expand your project with more resources weather resources are money, servers, or even customers.
Time Driven Development is when the project grows when time passes, or shrinks when time passes. Time-sensitive usually sacrifice other resources weather its money, quality, or quantity in order to get the right time.
Oh, btw, I just made these up, don't need to go looking them up :)
0. Research Driven Development
1. Documentation Driven Development
2. Community Driven Development
3. Test Driven Development
4. Resource Driven Development
5. Time Driven Development
Research Driven Development is when you need to research (learn) a bit, and do that bit, then research a bit, then do that bit, and so on ...
Documentation Driven Development is when you write the detailed documentation of the parts that you need, before actually implementing them in the project.
Not all projects require extensive documentations despite what most people try to tell you; but it's extremely helpful.
Community Driven Development is when the project is as big as its community of developers; sometimes that tasks cannot be handled by one person, so other experts will be included in the community and those experts are the ones that continue their parts of the project.
Test Driven Development is when you write a usage of the project, and then actually go and implement it. Many tools are available for this job.
Resource Driven Development is when you can only expand your project with more resources weather resources are money, servers, or even customers.
Time Driven Development is when the project grows when time passes, or shrinks when time passes. Time-sensitive usually sacrifice other resources weather its money, quality, or quantity in order to get the right time.
Oh, btw, I just made these up, don't need to go looking them up :)
If anyone is interested, we will have a package manager or some sort for it in the future.
We will not work on it straight away because the proposal is not ready (we just started it) yet.
I suggest everyone who's interested, you can add more details about the proposal; or even edit it completely.
Here you will find the draft for it:
https://gitlab.com/webpp/webpp/-/blob/package-manager/proposals/package-manager.md
We will not work on it straight away because the proposal is not ready (we just started it) yet.
I suggest everyone who's interested, you can add more details about the proposal; or even edit it completely.
Here you will find the draft for it:
https://gitlab.com/webpp/webpp/-/blob/package-manager/proposals/package-manager.md
GitLab
proposals/package-manager.md · package-manager · Web++ Group / Webpp
C++ Web Framework