Introduce foundation architectural support - #14
Draft
dieselxxx wants to merge 7 commits into
Draft
Conversation
… introduce Core/Foundation concepts **Details:** - Updated all badge links, URLs, and branch references in `README.md` to align with the new `architecture/foundation-support` branch. - Introduced detailed descriptions of Core/Foundation architectural layers, including dependency direction and separation of development responsibilities (Core → Foundation → Runtime). - Added milestones and pull request metadata to improve visibility of ongoing development efforts. - Expanded documentation to clarify goals for the Core layer: define stable architectural contracts while delegating developer-facing APIs to the Foundation layer. - Removed outdated or redundant sections for improved clarity and relevance. This update improves the consistency, readability, and alignment of the README with the FireHub project's evolving architecture and development practices.
dieselxxx
added
the
type: Architecture
2 tasks
2 tasks
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
dieselxxx
changed the title
architecture/foundation-support branch and…**Details:** - Introduced an abstract `Str` class in `Core-Standard/src/Type/Str.php` to define the foundational string-based Value Object type within the FireHub ecosystem. - Implements immutable string value semantics while serving as the base for domain-specific string extensions in higher-level layers (e.g., Foundation). - Provides a clear contract for string handling with its abstract `value(): string` method. - Aligns with the Core layer's goal of ensuring stable architectural contracts and PHP compatibility (`>=8.2`). This addition enhances the modularity and type safety of Core string operations, ensuring future extensibility and clear separation of responsibilities.
…h encoding support **Details:** - Added `Str::encoding()` and `Str::withEncoding()` methods in `Core-Standard/src/Type/Str.php` to provide string encoding introspection and mutation via an `Encoding` value object. Improves versatility for handling internationalization and character encoding scenarios. - Updated `ValueObject::equals()` in `Core-Standard/src/Type/ValueObject.php` to utilize `comparisonValue()` for equality checks, ensuring consistency in comparison logic across all Value Object subclasses. - Introduced protected `comparisonValue()` method in `ValueObject` to centralize comparison logic by delegating to the underlying value representation. - Adjusted `@uses` annotations in `ValueObject` doc comments for better clarity and alignment with new comparison logic. These updates enhance both the flexibility of the `Str` class for encoding management and the reliability of `ValueObject` comparison semantics, contributing to a more robust Core layer architecture.
**Details:** - Extended `Str` base Value Object to implement PHP's native `Stringable` interface, ensuring compatibility with type hints requiring `Stringable` in PHP `>=8.0`. - Introduced the `__toString()` method in `Str` to provide a native string representation of its value. This method utilizes `value()` for consistent output. - Updated class imports and doc comments to reflect the addition of the `Stringable` dependency and enhanced functionality. These changes enhance the interoperability of the `Str` class with both internal and external PHP components, improving compatibility and usability within the FireHub ecosystem.
…d `Char` type **Details:** - Extracted encoding-aware functionality from `Str` into a new `StringValue` abstract class in `Core-Standard/src/Type/StringValue.php`, preserving the immutable string value semantics. - Updated `Str` in `Core-Standard/src/Type/Str.php` to extend `StringValue`, simplifying its structure for domain-specific usage and aligning with Core's modular architecture. - Added `Char` abstract class in `Core-Standard/src/Type/Char.php` to define the base for character-based Value Objects. Ensures support for handling single characters with encoding awareness. - Updated class hierarchy to establish clear separation of concerns between general `StringValue` contracts and domain-specific `Str` and `Char` implementations. These changes enhance the modularity and extensibility of the Core layer, simplifying future extensions and reinforcing separation of architectural responsibilities.
…ar` objects **Details:** - Introduced an abstract `toChars(): array` method in the `Str` class within `Core-Standard/src/Type/Str.php`. - Provides a mechanism to split the immutable string value into a list of `Char<non-empty-string>` objects. - Enhances the extensibility of the `Str` class for character-level operations, aligning with the FireHub ecosystem's focus on modularity and type safety. This update lays the groundwork for fine-grained string manipulations, improving support for encoding-aware scenarios and future extensions.
**Details:** - Introduced an abstract `Boolean` class in `Core-Standard/src/Type/Boolean.php` to define the foundational boolean-based Value Object type within the FireHub ecosystem. - Implements immutable boolean value semantics while serving as the base for domain-specific boolean extensions in higher-level layers (e.g., Foundation). - Provides a clear contract for boolean handling with its abstract `value(): bool` method. - Aligns with the Core layer's focus on defining stable architectural contracts and PHP type safety (`>=8.2`). This addition strengthens the modularity, type safety, and extensibility of the Core layer, ensuring clarity and consistency for boolean-related operations within the FireHub project.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
… introduce Core/Foundation concepts
Details:
README.mdto align with the newarchitecture/foundation-support# 🧱 System Design / Architecture Pull RequestRelated Issue
Closes Introduce runtime foundation architectural support #12
Description
Define the architectural support required for the FireHub Foundation layer by introducing Core-level contracts for high-level abstractions.
Establish the system boundary between Core, Runtime, and Foundation:
This architecture is required to prevent Core components from depending directly on Foundation implementations while still allowing Core Value Objects, contracts, and framework components to reference fundamental high-level concepts.
The decision ensures that FireHub maintains a clean dependency direction:
Application
↓
Foundation
↓
Core Contracts
↑
Runtime
Affected Components
Core
Runtime
Foundation
Adapter
Capability
Architectural Rule
Core contracts MUST define only the minimum required behavior of an abstraction.
High-level APIs, fluent methods, transformations, and developer conveniences MUST remain in Foundation.
This separation allows FireHub to evolve Core, Runtime, and Foundation independently while preserving a stable architectural foundation.
Architecture Overview
System Design
Design Decisions
System Boundaries
Included
Excluded
Implementation
Core Changes
Contracts
Dependencies
Validation
Architecture Compliance
Build & Stability
Impact Analysis
Core Impact
Runtime Impact
Future Extensions
Risks / Constraints
Risk Level
Potential Risks
Documentation
Checklist
Notes
Technical Notes
Future Work
Reviewer Guidance