Hi, have to check that.
Do you know in how long the library chains can generally be? I mean if the main cpp code uses library1.h and the
library1.h uses
library2.h and
library3.h to function...
Library2.h uses 5.h and 6.h
Library3.h uses 7.h and 8.h
It seems the chains can grow
very big (not that sure how this works)
Could it be possible to issue a rule or "trademark" of some sort of limited chain (PURE) libraries. The way they could work is that they are not allowed to include other libraries at all. This way coder knows that this library does not form any additionl chains and make the compiling so time consuming and sometimes a bit fragile?
I asked this question from the AI too 
Yes, it’s entirely possible to define and adopt a “PURE” library standard where libraries are restricted from including other libraries. This approach could indeed simplify dependency management, reduce compilation time, and make codebases more predictable and maintainable. Here’s how such a rule or trademark might work:
What Are PURE Libraries?
• Definition: A PURE library is a self-contained library that does not include or depend on any other libraries.
• Purpose: Ensures the library does not form additional chains, keeping dependency graphs flat and manageable.
Rules for PURE Libraries
1. No External Includes:
• The library must only use core C++/Arduino headers like <Arduino.h>, <stdint.h>, or standard C++ headers (e.g., <cmath>).
• No includes of third-party libraries or other custom libraries.
2. Self-Contained Code:
• All necessary functionality must be implemented within the library itself or rely solely on Arduino core functionalities.
3. No Implicit Dependencies:
• The library cannot assume other libraries are included in the main sketch.
• The library must operate independently.
4. Minimal Functionality:
• Each PURE library should serve a single, well-defined purpose (single-responsibility principle).
Benefits of PURE Libraries
1. Faster Compilation:
• Since there are no nested #include chains, the preprocessor has less work to do, and compilation times are significantly reduced.
2. Improved Reliability:
• PURE libraries are less fragile because they avoid dependency conflicts or version mismatches with other libraries.
3. Simplified Debugging:
• A flat dependency structure makes it easier to identify where errors originate.
4. Predictable Behavior:
• Users know exactly what functionality the library provides without worrying about hidden dependencies or side effects.
5. Easier Integration:
• PURE libraries are easier to integrate into larger projects because they don’t add additional dependencies.
Challenges of PURE Libraries
1. Code Duplication:
• Without the ability to include other libraries, common functionality might need to be re-implemented in multiple libraries, leading to redundancy.
2. Limited Scope:
• PURE libraries are best suited for small, modular tasks. Complex libraries (e.g., those managing hardware like sensors or displays) often rely on other libraries for low-level functionality.
3. Lack of Extensibility:
• Without including other libraries, PURE libraries may be harder to extend or adapt to new requirements.
How PURE Libraries Could Work in Practice
1. PURE Certification/Trademark:
• Libraries adhering to the PURE standard could be labeled with a “PURE Certified” badge or trademark.
• This certification ensures developers know the library is self-contained and dependency-free.
2. Naming Convention:
• PURE libraries could follow a naming convention (e.g., PURE_Servo, PURE_Timer).
3. Development Guidelines:
• A formal set of rules and best practices could guide developers in creating PURE libraries.
4. Tooling Support:
• Arduino IDE or other development tools could include features to flag or validate PURE libraries.
Example of a PURE Library
PUREBlink.h:
#ifndef PUREBLINK_H
#define PUREBLINK_H
#include <Arduino.h> // Core Arduino functions only
class PUREBlink {
public:
PUREBlink(uint8_t pin);
void begin(); // Initialize the pin
void toggle(); // Toggle the pin state
void setInterval(unsigned long interval);
void update(); // Call in loop() to handle blinking
private:
uint8_t _pin;
unsigned long _interval;
unsigned long _lastToggle;
bool _state;
};
#endif
PUREBlink.cpp:
#include "PUREBlink.h"
PUREBlink::PUREBlink(uint8_t pin) : _pin(pin), _interval(1000), _lastToggle(0), _state(false) {}
void PUREBlink::begin() {
pinMode(_pin, OUTPUT);
}
void PUREBlink::toggle() {
_state = !_state;
digitalWrite(_pin, _state);
}
void PUREBlink::setInterval(unsigned long interval) {
_interval = interval;
}
void PUREBlink::update() {
if (millis() - _lastToggle >= _interval) {
toggle();
_lastToggle = millis();
}
}
Usage in Sketch:
#include <PUREBlink.h>
PUREBlink myBlink(13);
void setup() {
myBlink.begin();
myBlink.setInterval(500); // Blink every 500 ms
}
void loop() {
myBlink.update(); // Handles blinking
}
• This PURE library provides basic blinking functionality without relying on any external dependencies.
Real-World Applications
1. Small Embedded Systems:
• On devices with limited resources, PURE libraries ensure minimal memory usage and fast compilation.
2. Educational Projects:
• Students and beginners can use PURE libraries without worrying about complex dependency chains.
3. Certification for Industrial Use:
• In industrial applications, ensuring the reliability of libraries is crucial. PURE libraries provide predictable behavior.
Conclusion
PURE libraries offer a promising approach to simplify Arduino development by limiting dependency chains. While they may not be suitable for every scenario, they provide significant benefits in terms of reliability, maintainability, and performance. By establishing clear rules and promoting a certification standard, developers can create and share self-contained libraries that streamline development and reduce the challenges of dependency management.