From 9f778f5b8f81fe61b7ec53629b1e23832b1038f1 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 10:52:06 +0900 Subject: [PATCH 01/12] Refactor sidebar page assignments for English and Japanese to improve clarity and maintainability --- _includes/manuals/1.0/en/contents.html | 6 ++++-- _includes/manuals/1.0/ja/contents.html | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/_includes/manuals/1.0/en/contents.html b/_includes/manuals/1.0/en/contents.html index e3930fa..77626a0 100644 --- a/_includes/manuals/1.0/en/contents.html +++ b/_includes/manuals/1.0/en/contents.html @@ -16,14 +16,16 @@ diff --git a/_includes/manuals/1.0/ja/contents.html b/_includes/manuals/1.0/ja/contents.html index 707221b..7588b88 100644 --- a/_includes/manuals/1.0/ja/contents.html +++ b/_includes/manuals/1.0/ja/contents.html @@ -16,14 +16,16 @@ From c33989cab1e6333d74641480bbd4204ca4a74413 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 11:19:00 +0900 Subject: [PATCH 02/12] Fix language separation in navigation for GitHub Pages MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add explicit path-based filtering to ensure each language navigation only shows pages from its respective language directory. 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- _includes/manuals/1.0/en/contents.html | 7 ++++++- _includes/manuals/1.0/ja/contents.html | 7 ++++++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/_includes/manuals/1.0/en/contents.html b/_includes/manuals/1.0/en/contents.html index 77626a0..949b92f 100644 --- a/_includes/manuals/1.0/en/contents.html +++ b/_includes/manuals/1.0/en/contents.html @@ -16,15 +16,20 @@ - + \ No newline at end of file diff --git a/_includes/manuals/1.0/ja/contents.html b/_includes/manuals/1.0/ja/contents.html index 96f6f14..85bc93d 100644 --- a/_includes/manuals/1.0/ja/contents.html +++ b/_includes/manuals/1.0/ja/contents.html @@ -16,12 +16,10 @@ - + \ No newline at end of file From ac40a3b99e04bcd1ae95b5c505da5b96df56f4fa Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 11:41:18 +0900 Subject: [PATCH 04/12] Add automatic language detection for Learn More button MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Implement browser language detection similar to BEAR.Sunday: - Add 'intl' class to Learn More button - JavaScript detects navigator.language - Auto-redirect Japanese users to /ja/ manual - English users go to /en/ manual by default 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- index.html | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index e35a05b..f9b1755 100644 --- a/index.html +++ b/index.html @@ -11,7 +11,18 @@ The Ontological Programming Framework for PHP

- + Learn more » + From d187dadf97b4c26b0288ffc4c019f997f2f2ed0b Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 13:30:37 +0900 Subject: [PATCH 05/12] Add NewsWeek-style philosophical quotations and section headings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Added philosophical quotations to chapter openings in both languages - Implemented consistent NewsWeek-style formatting with proper attribution - Added section headings after quotations for better structure: - Chapter 1: "たず、これを芋おください" / "First, Look at This" - Chapter 2: "出発点" / "The Beginning" - Chapter 3: "内圚ず超越" / "Immanence Meets Transcendence" - Chapter 4: "終着点" / "The Destination" - Chapter 12: "あなたが発芋したもの" / "What You Have Discovered" - Enhanced Chapter 4 with $been concept integration and temporal completion - Unified philosophical framework across English and Japanese versions 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- manuals/1.0/en/01-overview.md | 6 +- manuals/1.0/en/02-input-classes.md | 6 ++ manuals/1.0/en/03-being-classes.md | 6 ++ manuals/1.0/en/04-final-objects.md | 6 ++ .../1.0/en/12-from-doing-to-being-final.md | 6 +- manuals/1.0/ja/01-overview.md | 6 +- manuals/1.0/ja/02-input-classes.md | 6 ++ manuals/1.0/ja/03-being-classes.md | 6 ++ manuals/1.0/ja/04-final-objects.md | 98 ++++++++++++++----- .../1.0/ja/12-from-doing-to-being-final.md | 6 +- 10 files changed, 125 insertions(+), 27 deletions(-) diff --git a/manuals/1.0/en/01-overview.md b/manuals/1.0/en/01-overview.md index 1dc98aa..3361b5f 100644 --- a/manuals/1.0/en/01-overview.md +++ b/manuals/1.0/en/01-overview.md @@ -5,7 +5,11 @@ category: Manual permalink: /manuals/1.0/en/01-overview.html --- -# Overview: A Different Way to Think About Code +# A Different Way to Think About Code + +> "The real voyage of discovery consists not in seeking new landscapes, but in having new eyes." +> +> —Marcel Proust, 'The Prisoner' (In Search of Lost Time, Volume 5) 1923 ## First, Look at This diff --git a/manuals/1.0/en/02-input-classes.md b/manuals/1.0/en/02-input-classes.md index 9720c34..54914ba 100644 --- a/manuals/1.0/en/02-input-classes.md +++ b/manuals/1.0/en/02-input-classes.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/en/02-input-classes.html # Input Classes +> "We begin from conditions we did not choose, and from there we build our existence." +> +> —From Heidegger's concept of Geworfenheit (thrownness) in 'Being and Time' (1927) + +## The Beginning + Input Classes are the starting point of every transformation in Be Framework. They contain only what the object itself possesses—no external dependencies. Think of it as the object's identity. These elements exist within the object, forming what we call the object's **Immanent Nature**. diff --git a/manuals/1.0/en/03-being-classes.md b/manuals/1.0/en/03-being-classes.md index d38d993..1acf9e2 100644 --- a/manuals/1.0/en/03-being-classes.md +++ b/manuals/1.0/en/03-being-classes.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/en/03-being-classes.html # Being Classes +> "The Way constantly does nothing, yet nothing is left undone." +> +> —Laozi, Tao Te Ching, Chapter 37 (6th century BC) + +## Immanence Meets Transcendence + Being Classes are where transformation actually occurs. The object's own nature (**Immanent Nature**) meets forces provided from the outside (**Transcendent Forces**), and a new being is born. If Input Classes are the "beginning," Being Classes express the "moment of change." diff --git a/manuals/1.0/en/04-final-objects.md b/manuals/1.0/en/04-final-objects.md index 45f2e3b..3fc7f06 100644 --- a/manuals/1.0/en/04-final-objects.md +++ b/manuals/1.0/en/04-final-objects.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/en/04-final-objects.html # Final Objects +> "You are not me. How can you know that I don't know the feelings of fish?" +> +> —Zhuangzi's reply when asked "You are not a fish. How can you know the feelings of fish?" (Zhuangzi, 4th century BC) + +## The Destination + Final Objects represent the destination of metamorphosis—complete, transformed beings that embody the user's actual interest. These are what the application ultimately cares about. ## Characteristics of Final Objects diff --git a/manuals/1.0/en/12-from-doing-to-being-final.md b/manuals/1.0/en/12-from-doing-to-being-final.md index 37157b0..5c63655 100644 --- a/manuals/1.0/en/12-from-doing-to-being-final.md +++ b/manuals/1.0/en/12-from-doing-to-being-final.md @@ -7,7 +7,11 @@ permalink: /manuals/1.0/en/12-from-doing-to-being-final.html # From Doing to Being: The Bigger Picture -> *"The real voyage of discovery consists not in seeking new landscapes, but in having new eyes."* — Marcel Proust +> "All things that exist are in the process of becoming." +> +> —Heraclitus, Fragments (c. 500 BC) + +## What You Have Discovered You've written Input Classes, created Being Classes, and watched objects transform rather than mutate. diff --git a/manuals/1.0/ja/01-overview.md b/manuals/1.0/ja/01-overview.md index caff87a..5faf23a 100644 --- a/manuals/1.0/ja/01-overview.md +++ b/manuals/1.0/ja/01-overview.md @@ -5,7 +5,11 @@ category: Manual permalink: /manuals/1.0/ja/01-overview.html --- -## 抂芁: 新しいパラダむム +# 抂芁 + +> 「真の発芋の航海は、新しい颚景を求めるこずではなく、新しい目を持぀こずにある。」 +> +> 　　—マルセル・プルヌスト『囚われの女』À la recherche du temps perdu 第5巻1923幎 ## たず、これを芋おください diff --git a/manuals/1.0/ja/02-input-classes.md b/manuals/1.0/ja/02-input-classes.md index 7e3f178..ff08507 100644 --- a/manuals/1.0/ja/02-input-classes.md +++ b/manuals/1.0/ja/02-input-classes.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/ja/02-input-classes.html # 入力クラス +> 「私たちは自分で遞択できない条件から始たり、そこから自分の存圚を築く」 +> +> 　　—ハむデガヌの被投性Geworfenheit抂念より『存圚ず時間』1927幎 + +## 出発点 + 入力クラスは、Beフレヌムワヌクにおけるすべおの倉容の出発点です。 ここにはオブゞェクト自身が持぀芁玠だけが含たれ、倖郚䟝存がありたせん。いわばオブゞェクトのアむデンティティです。オブゞェクトの内偎にあるものなので、これを**内圚的性質、むマナンスImmanence**ず呌びたす。 diff --git a/manuals/1.0/ja/03-being-classes.md b/manuals/1.0/ja/03-being-classes.md index 0b1d419..423b2e0 100644 --- a/manuals/1.0/ja/03-being-classes.md +++ b/manuals/1.0/ja/03-being-classes.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/ja/03-being-classes.html # 存圚クラス +> 「道垞無為而無䞍為」 +> +> —道は垞に無為にしお、而も為さざるこずなし老子『道埳経』第䞉十䞃章　玀元前6䞖玀 + +## 内圚ず超越 + 存圚クラスは倉容が実際に起こる堎所です。 オブゞェクト自身が持぀性質**内圚的性質むマナンス**ず、倖郚から提䟛される力**超越的な力トランセンデンス**が出䌚い、次の新しい存圚が生たれたす。入力クラスが「始たり」なら、存圚クラスは「倉わる瞬間」を衚珟したす。 diff --git a/manuals/1.0/ja/04-final-objects.md b/manuals/1.0/ja/04-final-objects.md index e3f2713..077ee58 100644 --- a/manuals/1.0/ja/04-final-objects.md +++ b/manuals/1.0/ja/04-final-objects.md @@ -7,19 +7,39 @@ permalink: /manuals/1.0/ja/04-final-objects.html # 最終オブゞェクト -最終オブゞェクトは倉容の目的地を衚したす—ナヌザヌの実際の関心を䜓珟する、完党で倉容した存圚です。これらはアプリケヌションが最終的に気にかけるものです。 +> 「あなたは私ではない。どうしお私が魚の気持ちを知らないず分かるのか」 +> +> —「あなたは魚ではない。どうしお魚の気持ちが分かるのか」ず問われた時に荘子が返した蚀葉 『荘子』玀元前4䞖玀 + +## 終着点 + +最終オブゞェクトは倉容の旅路の到達点です。 +ナヌザヌが求める䟡倀、アプリケヌションが届けたい結果が具珟化された、完党で最終的な存圚です。 + +これは入力クラスから始たった内圚的性質むマナンスが、様々な超越的力トランセンデンスず出䌚い、自然な倉容を経お達成した最終圢態です。アリストテレスの蚀う゚ンテレケむア、すなわち朜圚性が完党に珟実化された状態を䜓珟しおいたす。 ## 最終オブゞェクトの特城 -**完党な存圚**: 最終オブゞェクトは意図された目的のためにさらなる倉容を必芁ずしない、完党に圢成された゚ンティティです。 +**完党性゚ンテレケむア**: これ以䞊の倉容を必芁ずしない、完党に珟実化された存圚です。 + +**ナヌザヌ䟡倀の実珟**: ナヌザヌが本圓に必芁ずするもの、意味のあるデヌタや操䜜の成功結果を衚珟したす。 + +**豊かな状態**: 入力クラスずは察照的に、最終オブゞェクトはドメむンの豊富さを完党に衚珟した存圚です。 + +## 時間的存圚の完党性 + +ここで興味深い問いがありたす。テストが䞍芁になるほどの完党性を持぀オブゞェクトがあったらどうでしょう -**ナヌザヌ䞭心**: これらはナヌザヌが実際に欲しいもの—成功した操䜜、意味のあるデヌタ、実行可胜な結果を衚したす。 +Be Frameworkでは、オブゞェクトの時間的存圚を二぀の軞で捉えたす -**豊富な状態**: 入力クラスずは異なり、最終オブゞェクトは倉容されたデヌタの完党な豊かさを含みたす。 +- **`#[Be]`**: なりたい自分、向かう先未来ぞの方向性 +- **`$been`**: 完了した自分過去完了の自己蚌明 + +埓来のプログラミングでは、オブゞェクトが正しく凊理されたかどうかを倖郚のテストで怜蚌したす。しかし、オブゞェクト自身が完了の蚌拠を内包しおいたらどうでしょう倖郚による怜蚌ではなく、内圚的な自己蚌明が可胜になりたす。 ## 䟋 -### 成功した結果 +### 内圚的自己蚌明を持぀結果 ```php final class SuccessfulOrder { @@ -27,51 +47,79 @@ final class SuccessfulOrder public readonly string $confirmationCode; public readonly DateTimeImmutable $timestamp; public readonly string $message; + public readonly BeenProcessed $been; // 自己蚌明 public function __construct( - #[Input] Money $total, // 怜蚌からの内圚的 - #[Input] CreditCard $card, // 怜蚌からの内圚的 - #[Inject] OrderIdGenerator $generator, // 超越的 - #[Inject] Receipt $receipt // 超越的 + #[Input] Money $total, // 内圚的性質 + #[Input] CreditCard $card, // 内圚的性質 + #[Inject] OrderIdGenerator $generator, // 超越的力 + #[Inject] Receipt $receipt // 超越的力 ) { - $this->orderId = $generator->generate(); // 新しい内圚的 - $this->confirmationCode = $receipt->generate($total); // 新しい内圚的 - $this->timestamp = new DateTimeImmutable(); // 新しい内圚的 - $this->message = "泚文確認: {$this->orderId}"; // 新しい内圚的 + $this->orderId = $generator->generate(); // 新しい内圚的性質 + $this->confirmationCode = $receipt->generate($total); // 新しい内圚的性質 + $this->timestamp = new DateTimeImmutable(); // 新しい内圚的性質 + $this->message = "泚文確認: {$this->orderId}"; // 新しい内圚的性質 + + // 完了の自己蚌明 + $this->been = new BeenProcessed( + actor: $card->getHolderName(), + timestamp: $this->timestamp, + evidence: [ + 'total' => $total->getAmount(), + 'payment_method' => $card->getType(), + 'confirmation' => $this->confirmationCode + ] + ); } } ``` -### 最終オブゞェクトずしおの゚ラヌ状態 +このオブゞェクトは倖郚テストを必芁ずしたせん。`$been`プロパティが完了の完党な蚌拠を内包しおいるからです。 + +### ゚ラヌ状態の自己蚌明 ```php final class FailedOrder { public readonly string $errorCode; public readonly string $message; public readonly DateTimeImmutable $timestamp; + public readonly BeenRejected $been; // 倱敗の自己蚌明 public function __construct( - #[Input] array $errors, // 怜蚌からの内圚的 - #[Inject] Logger $logger, // 超越的 - #[Inject] ErrorCodeGenerator $generator // 超越的 + #[Input] array $errors, // 内圚的性質 + #[Inject] Logger $logger, // 超越的力 + #[Inject] ErrorCodeGenerator $generator // 超越的力 ) { $this->errorCode = $generator->generate(); $this->message = "泚文倱敗: " . implode(', ', $errors); $this->timestamp = new DateTimeImmutable(); + // 倱敗の自己蚌明 + $this->been = new BeenRejected( + reason: 'validation_failed', + timestamp: $this->timestamp, + evidence: [ + 'error_count' => count($errors), + 'error_types' => array_keys($errors), + 'error_code' => $this->errorCode + ] + ); + $logger->logOrderFailure($this->errorCode, $errors); // 副䜜甚 } } ``` +成功も倱敗も、どちらも完了の自己蚌明を持ちたす。倖郚テストではなく、オブゞェクト自身が䜕が起こったかの完党な蚘録を保持しおいるのです。 + ## 最終オブゞェクト vs 入力クラス | 入力クラス | 最終オブゞェクト | |-----------|-----------------| -| 玔粋なアむデンティティ | 豊富で倉容した状態 | -| 出発点 | 目的地 | +| 玔粋なアむデンティティ | 豊かで倉容した状態 | +| 倉容の出発点 | 倉容の到達点 | | ナヌザヌが提䟛するもの | ナヌザヌが受け取るもの | -| 単玔な構造 | 完党な機胜 | +| シンプルな構造 | 完党に実珟された機胜 | ## 耇数の最終的運呜 @@ -99,8 +147,12 @@ if ($order->being instanceof SuccessfulOrder) { 2. **存圚クラス**: 倉容段階「これが私の倉化の仕方です」 3. **最終オブゞェクト**: 完党な結果「これが私がなったものです」 -ナヌザヌは䞻に入力圌らが提䟛するものず最終オブゞェクト圌らが受け取るものに関心を持ちたす。間にある存圚クラスはフレヌムワヌクの責任です—意図ず結果の間の橋を䜜る倉容の機械です。 +ナヌザヌは䞻に入力圌らが提䟛するものず最終オブゞェクト圌らが受け取るものに関心を持ちたす。間にある存圚クラスは私たち蚭蚈者の責任です。意図ず結果の間の橋枡しをするためにドメむンの時間的倉容をよく理解し、その倉容の仕組みを蚭蚈するこずが重芁です。 + +## 倉容の完成 + +最終オブゞェクトは、゚ンテレケむア完党実珟の状態を衚珟したす。倉容の必芁がもうない、完党に実珟された存圚です。 -## 自然な完成 +入力クラスから始たった内圚的性質むマナンスが、様々な超越的力トランセンデンスず出䌚いながら自然な倉容を経お、぀いに到達した完成圢です。ここにはもう「なろうずする」努力も、「倉わろうずする」意図もありたせん。すべおが完了し、ナヌザヌが本圓に求めおいた䟡倀がここに実珟されおいたす。私たちのシステムの本質的な䟡倀です。 -最終オブゞェクトは自然な倉容の完成を䜓珟したす。これらはもう䜕かを「する」必芁がありたせん—単玔に、元の入力が䞖界の胜力ず出䌚うこずから生たれるこずを意図された結果*である*のです。 \ No newline at end of file +これこそが、Be Frameworkが目指すプログラミングの到達点—「䜕をするか」ではなく「䜕であるか」が䜓珟された存圚です。 diff --git a/manuals/1.0/ja/12-from-doing-to-being-final.md b/manuals/1.0/ja/12-from-doing-to-being-final.md index a915665..958f410 100644 --- a/manuals/1.0/ja/12-from-doing-to-being-final.md +++ b/manuals/1.0/ja/12-from-doing-to-being-final.md @@ -7,7 +7,11 @@ permalink: /manuals/1.0/ja/12-from-doing-to-being-final.html # Doingから Beingぞ: より倧きな芖点 -> *「真の発芋の航海は、新しい颚景を求めるこずではなく、新しい目を持぀こずにある。」* — マルセル・プルヌスト +> 「存圚するものは党お生成の途䞊にある」 +> +> 　　—ヘラクレむトス『断片』玀元前500幎頃 + +## あなたが発芋したもの あなたは入力クラスを曞き、存圚クラスを䜜成し、オブゞェクトが倉異するのではなく倉容するのを芋おきたした。 From b115013f9f52c21e8ec16ab215545417260c3f48 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 13:31:53 +0900 Subject: [PATCH 06/12] Improve Laozi quotation translation in Chapter 3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change "The Way constantly does nothing" to "The Tao does nothing" for more accurate and concise philosophical expression. 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- manuals/1.0/en/03-being-classes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manuals/1.0/en/03-being-classes.md b/manuals/1.0/en/03-being-classes.md index 1acf9e2..c7fe6f7 100644 --- a/manuals/1.0/en/03-being-classes.md +++ b/manuals/1.0/en/03-being-classes.md @@ -7,7 +7,7 @@ permalink: /manuals/1.0/en/03-being-classes.html # Being Classes -> "The Way constantly does nothing, yet nothing is left undone." +> "The Tao does nothing, yet nothing is left undone." > > —Laozi, Tao Te Ching, Chapter 37 (6th century BC) From 2871cc8ec5b9a8233636b7795546405c334f1aba Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 13:39:21 +0900 Subject: [PATCH 07/12] Complete $been concept integration in English Chapter 4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Added Temporal Completeness section with #[Be] and $been axes - Integrated intrinsic self-evidence with BeenProcessed and BeenRejected examples - Enhanced both success and failure objects with complete temporal evidence - Added philosophical conclusion about entelecheia and transformation completion - Unified English and Japanese versions with identical $been concept depth 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- manuals/1.0/en/04-final-objects.md | 75 +++++++++++++++++++++++------- 1 file changed, 59 insertions(+), 16 deletions(-) diff --git a/manuals/1.0/en/04-final-objects.md b/manuals/1.0/en/04-final-objects.md index 3fc7f06..d0aa83f 100644 --- a/manuals/1.0/en/04-final-objects.md +++ b/manuals/1.0/en/04-final-objects.md @@ -23,9 +23,20 @@ Final Objects represent the destination of metamorphosis—complete, transformed **Rich State**: Unlike Input Classes, Final Objects contain the full richness of transformed data. +## Temporal Completeness + +Here's an intriguing question: What if objects had such completeness that they needed no external testing? + +The Be Framework captures the temporal existence of objects along two axes: + +- **`#[Be]`**: The intended self, the destination (future directionality) +- **`$been`**: The completed self (past perfect self-evidence) + +Traditional programming verifies whether objects have been processed correctly through external tests. But what if objects themselves contained evidence of their completion? Instead of external verification, intrinsic self-evidence becomes possible. + ## Examples -### Successful Outcomes +### Intrinsic Self-Evidence ```php final class SuccessfulOrder { @@ -33,43 +44,71 @@ final class SuccessfulOrder public readonly string $confirmationCode; public readonly DateTimeImmutable $timestamp; public readonly string $message; + public readonly BeenProcessed $been; // Self-evidence public function __construct( - #[Input] Money $total, // Immanent from validation - #[Input] CreditCard $card, // Immanent from validation - #[Inject] OrderIdGenerator $generator, // Transcendent - #[Inject] Receipt $receipt // Transcendent + #[Input] Money $total, // Immanent nature + #[Input] CreditCard $card, // Immanent nature + #[Inject] OrderIdGenerator $generator, // Transcendent force + #[Inject] Receipt $receipt // Transcendent force ) { - $this->orderId = $generator->generate(); // New Immanent - $this->confirmationCode = $receipt->generate($total); // New Immanent - $this->timestamp = new DateTimeImmutable(); // New Immanent - $this->message = "Order confirmed: {$this->orderId}"; // New Immanent + $this->orderId = $generator->generate(); // New immanent nature + $this->confirmationCode = $receipt->generate($total); // New immanent nature + $this->timestamp = new DateTimeImmutable(); // New immanent nature + $this->message = "Order confirmed: {$this->orderId}"; // New immanent nature + + // Self-evidence of completion + $this->been = new BeenProcessed( + actor: $card->getHolderName(), + timestamp: $this->timestamp, + evidence: [ + 'total' => $total->getAmount(), + 'payment_method' => $card->getType(), + 'confirmation' => $this->confirmationCode + ] + ); } } ``` -### Error States as Final Objects +This object requires no external testing. The `$been` property contains complete evidence of completion. + +### Error States with Self-Evidence ```php final class FailedOrder { public readonly string $errorCode; public readonly string $message; public readonly DateTimeImmutable $timestamp; + public readonly BeenRejected $been; // Self-evidence of failure public function __construct( - #[Input] array $errors, // Immanent from validation - #[Inject] Logger $logger, // Transcendent - #[Inject] ErrorCodeGenerator $generator // Transcendent + #[Input] array $errors, // Immanent nature + #[Inject] Logger $logger, // Transcendent force + #[Inject] ErrorCodeGenerator $generator // Transcendent force ) { $this->errorCode = $generator->generate(); $this->message = "Order failed: " . implode(', ', $errors); $this->timestamp = new DateTimeImmutable(); + // Self-evidence of failure + $this->been = new BeenRejected( + reason: 'validation_failed', + timestamp: $this->timestamp, + evidence: [ + 'error_count' => count($errors), + 'error_types' => array_keys($errors), + 'error_code' => $this->errorCode + ] + ); + $logger->logOrderFailure($this->errorCode, $errors); // Side effect } } ``` +Both success and failure carry their own self-evidence of completion. Instead of external tests, the objects themselves maintain complete records of what occurred. + ## Final Objects vs Input Classes | Input Classes | Final Objects | @@ -105,8 +144,12 @@ The path from Input to Final Object represents a complete transformation journey 2. **Being Classes**: Transformation stages ("Here's how I change") 3. **Final Object**: Complete result ("Here's what I became") -Users primarily care about Input (what they provide) and Final Objects (what they get back). The Being Classes in between are the framework's responsibility—the machinery of transformation that creates the bridge between intention and result. +Users primarily care about Input (what they provide) and Final Objects (what they get back). The Being Classes in between are our responsibility as designers. It's crucial to understand the temporal transformation of the domain well and design the mechanisms of that transformation to bridge intention and result. + +## Transformation Complete + +Final Objects express the state of entelecheia (complete realization). They are fully realized beings that no longer need transformation. -## Natural Completion +The immanent nature that began with Input Classes, through encounters with various transcendent forces and natural transformation, finally reaches this completed form. There is no more "trying to become" or "intending to change." Everything is complete, and the value that users truly sought is realized here. This is the essential value of our system. -Final Objects embody the completion of natural transformation. They don't need to "do" anything more—they simply *are* the result that was meant to emerge from the original input's encounter with the world's capabilities. +This is the destination that Be Framework aims for in programming—existence that embodies not "what to do" but "what to be." From 35b11a2b485823d10b3b5ffed0ebb1a7ad205640 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 14:10:17 +0900 Subject: [PATCH 08/12] Restructure Chapter 5 to eliminate redundancy and enhance clarity MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Added Heraclitus philosophical quotation with proper NewsWeek-style formatting - Added "倉容の流れ" / "Patterns of Change" section headings after quotations - Consolidated redundant "Branching Destinies" and "Conditional Transformation" into unified "Conditional Branching Pattern" - Removed obvious "Fork-Join Pattern" that was just parallel data collection - Enhanced "Self-Organizing Pipelines" section with UNIX pipes comparison - Updated pattern selection list to remove redundancy - Improved final message to be more natural - Applied consistent structure across both Japanese and English versions 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- manuals/1.0/en/05-metamorphosis-patterns.md | 86 ++++++++++----------- manuals/1.0/ja/05-metamorphosis-patterns.md | 85 ++++++++++---------- 2 files changed, 85 insertions(+), 86 deletions(-) diff --git a/manuals/1.0/en/05-metamorphosis-patterns.md b/manuals/1.0/en/05-metamorphosis-patterns.md index 42a80e8..eda5d4b 100644 --- a/manuals/1.0/en/05-metamorphosis-patterns.md +++ b/manuals/1.0/en/05-metamorphosis-patterns.md @@ -7,7 +7,13 @@ permalink: /manuals/1.0/en/05-metamorphosis-patterns.html # Metamorphosis Patterns -Be Framework supports various patterns of transformation, from simple linear chains to complex branching destinies. Understanding these patterns helps you design natural transformation flows. +> "No man ever steps in the same river twice." +> +> —Heraclitus, Fragments (c. 500 BC) + +## Patterns of Change + +Be Framework supports various patterns of transformation, from simple linear chains to complex branching. Understanding these patterns helps you design natural transformation flows. ## Linear Metamorphic Chain @@ -32,9 +38,9 @@ final class WelcomeMessage { /* ... */ } Each stage naturally leads to the next, like a river flowing to the sea. -## Branching Destinies +## Conditional Branching Pattern -Objects can have multiple possible futures based on their nature: +Objects can have multiple possible futures based on their nature. This is natural transformation that branches into different types based on conditions: ```php #[Be([ApprovedApplication::class, RejectedApplication::class])] @@ -55,42 +61,9 @@ final class ApplicationReview } ``` -The object determines its own destiny through **Type-Driven Metamorphosis**. - -## Fork-Join Pattern - -A single input branches into parallel transformations that later converge: - -```php -#[Be(PersonalizedRecommendation::class)] -final class UserAnalysis -{ - public readonly PersonalizedRecommendation $being; - - public function __construct( - #[Input] string $userId, // Immanent - #[Inject] BehaviorAnalyzer $behavior, // Transcendent - #[Inject] PreferenceAnalyzer $preference, // Transcendent - #[Inject] SocialAnalyzer $social // Transcendent - ) { - // Parallel analysis - $behaviorScore = $behavior->analyze($userId); - $preferenceScore = $preference->analyze($userId); - $socialScore = $social->analyze($userId); - - // Convergence - $this->being = new PersonalizedRecommendation( - $behaviorScore, - $preferenceScore, - $socialScore - ); - } -} -``` - -## Conditional Transformation +### Other Conditional Branching Examples -Sometimes transformation depends on runtime conditions: +Feature levels and permissions follow the same pattern: ```php #[Be([PremiumFeatures::class, BasicFeatures::class])] @@ -111,6 +84,10 @@ final class FeatureActivation } ``` +The object determines its own destiny through **Type-Driven Metamorphosis**. + + + ## Nested Metamorphosis Complex objects can contain their own transformation chains: @@ -134,7 +111,26 @@ final class OrderProcessing ## Self-Organizing Pipelines -The beauty of these patterns is that they're **self-organizing**. Objects declare their own destinies, and the framework naturally follows the transformation paths without external orchestration. +The beauty of these patterns is that they're **self-organizing**. Like UNIX pipes that combine simple commands to create powerful systems, Be Framework combines typed objects to create natural transformation flows. + +### Comparison with UNIX Pipes + +```bash +# UNIX: Text flows through externally controlled pipelines +cat access.log | grep "404" | awk '{print $7}' | sort | uniq -c +``` + +```php +// Be Framework: Rich objects flow through intrinsically controlled pipelines +$finalObject = $becoming(new ApplicationInput($documents)); +// Objects themselves know their next transformation destination +``` + +Key evolution: +- **UNIX**: External shell controls the pipeline +- **Be Framework**: Objects declare their own destiny with `#[Be()]` + +### Self-Organization in Action ```php // No controllers, no orchestrators—just natural flow @@ -147,14 +143,18 @@ match (true) { }; ``` +This self-organization provides: +- No external orchestration needed +- Type safety maintained +- Capabilities provided through dependency injection +- Testable independent components + ## Pattern Selection Choose patterns based on your domain's natural flow: - **Linear**: Sequential processes (validation → processing → completion) -- **Branching**: Decision points (approve/reject, success/failure) -- **Fork-Join**: Parallel analysis that converges -- **Conditional**: Feature flags, permissions, subscriptions +- **Conditional Branching**: Decision points (approve/reject, success/failure, permission levels) - **Nested**: Complex operations with sub-processes -The key is to let the transformation emerge naturally from the domain logic, not force it into artificial patterns. +The key is to let transformation emerge naturally from the domain's flow, not force it into artificial patterns. diff --git a/manuals/1.0/ja/05-metamorphosis-patterns.md b/manuals/1.0/ja/05-metamorphosis-patterns.md index 543afbc..d1e81f1 100644 --- a/manuals/1.0/ja/05-metamorphosis-patterns.md +++ b/manuals/1.0/ja/05-metamorphosis-patterns.md @@ -7,7 +7,13 @@ permalink: /manuals/1.0/ja/05-metamorphosis-patterns.html # 倉容パタヌン -Beフレヌムワヌクは、単玔な線圢チェヌンから耇雑な分岐する運呜たで、様々な倉容パタヌンをサポヌトしたす。これらのパタヌンを理解するこずで、自然な倉容フロヌを蚭蚈できたす。 +> 「同じ川に二床入るこずはできない」 +> +> 　　—ヘラクレむトス『断片』玀元前500幎頃 + +## 倉容の流れ + +Beフレヌムワヌクは、単玔な線圢チェヌンから耇雑な分岐たで、様々な倉容パタヌンをサポヌトしたす。これらのパタヌンを理解するこずで、自然な倉容フロヌを蚭蚈できたす。 ## 線圢倉容チェヌン @@ -32,9 +38,9 @@ final class WelcomeMessage { /* ... */ } 各段階は自然に次ぞず導かれ、川が海に流れるようです。 -## 分岐する運呜 +## 条件分岐パタヌン -オブゞェクトはその性質に基づいお耇数の可胜な未来を持぀こずができたす +オブゞェクトはその性質に基づいお耇数の可胜な未来を持぀こずができたす。これは条件によっお異なる型ぞず分岐する自然な倉容です ```php #[Be([ApprovedApplication::class, RejectedApplication::class])] @@ -55,42 +61,9 @@ final class ApplicationReview } ``` -オブゞェクトは**型駆動倉容**を通しお自身の運呜を決定したす。 - -## フォヌク・ゞョむンパタヌン +### 他の条件分岐䟋 -単䞀の入力が䞊列倉容に分岐し、埌に収束したす - -```php -#[Be(PersonalizedRecommendation::class)] -final class UserAnalysis -{ - public readonly PersonalizedRecommendation $being; - - public function __construct( - #[Input] string $userId, // 内圚的 - #[Inject] BehaviorAnalyzer $behavior, // 超越的 - #[Inject] PreferenceAnalyzer $preference, // 超越的 - #[Inject] SocialAnalyzer $social // 超越的 - ) { - // 䞊列分析 - $behaviorScore = $behavior->analyze($userId); - $preferenceScore = $preference->analyze($userId); - $socialScore = $social->analyze($userId); - - // 収束 - $this->being = new PersonalizedRecommendation( - $behaviorScore, - $preferenceScore, - $socialScore - ); - } -} -``` - -## 条件付き倉容 - -時ずしお倉容はランタむム条件に䟝存したす +機胜レベルや暩限による分岐も同様のパタヌンです ```php #[Be([PremiumFeatures::class, BasicFeatures::class])] @@ -111,6 +84,9 @@ final class FeatureActivation } ``` +オブゞェクトは**型駆動倉容**を通しお自身の運呜を決定したす。 + + ## ネストした倉容 耇雑なオブゞェクトは独自の倉容チェヌンを含むこずができたす @@ -134,7 +110,26 @@ final class OrderProcessing ## 自己組織化パむプラむン -これらのパタヌンの矎しさは、それらが**自己組織化**であるこずです。オブゞェクトは自身の運呜を宣蚀し、フレヌムワヌクは倖郚のオヌケストレヌションなしに自然に倉容パスに埓いたす。 +これらのパタヌンの矎しさは、それらが**自己組織化**であるこずです。Unixパむプが単玔なコマンドを組み合わせお匷力なシステムを䜜るように、Beフレヌムワヌクは型付きオブゞェクトを組み合わせお自然な倉容の流れを䜜りたす。 + +### Unixパむプずの比范 + +```bash +# Unix: テキストが流れる倖郚制埡のパむプラむン +cat access.log | grep "404" | awk '{print $7}' | sort | uniq -c +``` + +```php +// Be Framework: リッチなオブゞェクトが流れる内圚的制埡のパむプラむン +$finalObject = $becoming(new ApplicationInput($documents)); +// オブゞェクト自身が次の倉容先を知っおいる +``` + +重芁な進化 +- **Unix**: 倖郚のshellがパむプを制埡 +- **Be Framework**: オブゞェクト自身が`#[Be()]`で運呜を宣蚀 + +### 自己組織化の実珟 ```php // コントロヌラヌもオヌケストレヌタヌもなし—ただ自然な流れ @@ -147,14 +142,18 @@ match (true) { }; ``` +この自己組織化により +- 倖郚オヌケストレヌションが䞍芁 +- 型安党性が保たれる +- 䟝存性泚入による胜力の提䟛 +- テスト可胜な独立したコンポヌネント + ## パタヌンの遞択 ドメむンの自然な流れに基づいおパタヌンを遞択しおください - **線圢**: 順次プロセス怜蚌 → 凊理 → 完了 -- **分岐**: 決定ポむント承認/拒吊、成功/倱敗 -- **フォヌク・ゞョむン**: 収束する䞊列分析 -- **条件付き**: 機胜フラグ、暩限、サブスクリプション +- **条件分岐**: 決定ポむント承認/拒吊、成功/倱敗、暩限レベル - **ネストした**: サブプロセスを持぀耇雑な操䜜 -重芁なのは、倉容をドメむンロゞックから自然に生たれさせるこずであり、人工的なパタヌンに匷制するこずではありたせん。 \ No newline at end of file +重芁なのは、倉容をドメむンの自然な流れから生たれさせるこずであり、人工的なパタヌンに匷制するこずではありたせん。 From 2e68a7124124c3d2214fd948401391e4003bae55 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 15:08:17 +0900 Subject: [PATCH 09/12] Restructure Chapter 5: From Patterns to Metamorphosis Philosophy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Transform Chapter 5 from pattern catalog to philosophical overview of metamorphosis, integrating Einstein's space-time inseparability with Heraclitean flow philosophy. Major changes: - Replace Heraclitean quote with Einstein's authentic 1916 general relativity quote - Add core concept: time and domain cannot be separated - Restructure from pattern-focused to essence-focused metamorphosis overview - Replace linear patterns with temporal flow (T0→T1→T2→T3) - Rename conditional branching to "self-determination of destiny" - Remove quantum superposition section for practical balance - Add comprehensive implementation guidelines - Conclude with Heraclitean philosophy connecting to Be Framework essence Both Japanese and English versions updated with philosophical depth while maintaining practical utility as framework documentation. 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- manuals/1.0/en/05-metamorphosis-patterns.md | 133 ++++++++++++------- manuals/1.0/ja/05-metamorphosis-patterns.md | 136 +++++++++++++------- 2 files changed, 171 insertions(+), 98 deletions(-) diff --git a/manuals/1.0/en/05-metamorphosis-patterns.md b/manuals/1.0/en/05-metamorphosis-patterns.md index eda5d4b..8568e29 100644 --- a/manuals/1.0/en/05-metamorphosis-patterns.md +++ b/manuals/1.0/en/05-metamorphosis-patterns.md @@ -1,46 +1,46 @@ --- layout: docs-en -title: "5. Metamorphosis Patterns" +title: "5. Metamorphosis" category: Manual -permalink: /manuals/1.0/en/05-metamorphosis-patterns.html +permalink: /manuals/1.0/en/05-metamorphosis.html --- -# Metamorphosis Patterns +# Metamorphosis -> "No man ever steps in the same river twice." +> "Space and time cannot be defined independently of each other." > -> —Heraclitus, Fragments (c. 500 BC) +> —Albert Einstein, The Foundation of the General Theory of Relativity (1916) -## Patterns of Change +## Time and Domain Are Inseparable -Be Framework supports various patterns of transformation, from simple linear chains to complex branching. Understanding these patterns helps you design natural transformation flows. +Just as Einstein discovered the inseparability of time and space, the Be Framework considers time and domain as a single entity that cannot be divided. Approval processes have their approval time, payments have their payment time, and transformation naturally emerges along the unique temporal axis that each domain logic possesses. -## Linear Metamorphic Chain +## Irreversible Flow of Time -The simplest pattern: A → B → C → D +Object metamorphosis follows the arrow of time in a unidirectional flow. There is no returning to the past, no remaining in the same moment: ```php -// Input +// Time T0: Birth of input #[Be(EmailValidation::class)] final class EmailInput { /* ... */ } -// First transformation +// Time T1: First metamorphosis (T0 is already past) #[Be(UserCreation::class)] final class EmailValidation { /* ... */ } -// Second transformation +// Time T2: Second metamorphosis (T1 becomes memory) #[Be(WelcomeMessage::class)] final class UserCreation { /* ... */ } -// Final result +// Time T3: Final existence (encompassing all past) final class WelcomeMessage { /* ... */ } ``` -Each stage naturally leads to the next, like a river flowing to the sea. +Each moment never returns, and new existence preserves previous forms as memory within itself. Like a river flowing, time moves only in one direction. -## Conditional Branching Pattern +## Self-Determination of Destiny -Objects can have multiple possible futures based on their nature. This is natural transformation that branches into different types based on conditions: +Like living beings in reality, objects determine their own destiny through the interaction between intrinsic nature and external environment. This is not following a predetermined route, but natural metamorphosis responding to the circumstances of that moment: ```php #[Be([ApprovedApplication::class, RejectedApplication::class])] @@ -49,11 +49,12 @@ final class ApplicationReview public readonly ApprovedApplication|RejectedApplication $being; public function __construct( - #[Input] array $documents, // Immanent - #[Inject] ReviewService $reviewer // Transcendent + #[Input] array $documents, // Intrinsic nature + #[Inject] ReviewService $reviewer // External environment ) { $result = $reviewer->evaluate($documents); + // Destiny is decided at this very moment $this->being = $result->isApproved() ? new ApprovedApplication($documents, $result->getScore()) : new RejectedApplication($result->getReasons()); @@ -61,31 +62,6 @@ final class ApplicationReview } ``` -### Other Conditional Branching Examples - -Feature levels and permissions follow the same pattern: - -```php -#[Be([PremiumFeatures::class, BasicFeatures::class])] -final class FeatureActivation -{ - public readonly PremiumFeatures|BasicFeatures $being; - - public function __construct( - #[Input] User $user, // Immanent - #[Inject] SubscriptionService $service // Transcendent - ) { - $subscription = $service->getSubscription($user); - - $this->being = $subscription->isPremium() - ? new PremiumFeatures($user, $subscription) - : new BasicFeatures($user); - } -} -``` - -The object determines its own destiny through **Type-Driven Metamorphosis**. - ## Nested Metamorphosis @@ -149,12 +125,71 @@ This self-organization provides: - Capabilities provided through dependency injection - Testable independent components -## Pattern Selection +## Implementation Guidelines + +### When to Choose Linear Metamorphosis + +For sequential processing where each stage prepares the data needed for the next: + +```php +User Registration → Email Verification → Account Activation → Welcome Notification +``` + +This is suitable when failure at any stage should halt the entire process. + +### When to Choose Conditional Branching + +When the same input branches into different results based on nature or permissions: + +```php +// Implementation example: Feature differentiation by payment capability +#[Be([FullAccess::class, LimitedAccess::class, ReadOnlyAccess::class])] +final class AccessDetermination +{ + public readonly FullAccess|LimitedAccess|ReadOnlyAccess $being; + + public function __construct( + #[Input] User $user, + #[Inject] PaymentStatus $payment + ) { + $this->being = match($payment->getStatus()) { + 'premium' => new FullAccess($user, $payment->getFeatures()), + 'basic' => new LimitedAccess($user, $payment->getLimits()), + default => new ReadOnlyAccess($user) + }; + } +} +``` + +### When to Choose Nested Metamorphosis + +When executing multiple independent processes in parallel and aggregating their results: + +```php +final class OrderCompletion +{ + public function __construct( + #[Input] OrderData $order, + #[Inject] Becoming $becoming + ) { + // Independent parallel processing + $this->inventory = $becoming(new InventoryCheck($order->items)); + $this->payment = $becoming(new PaymentProcess($order->payment)); + $this->shipping = $becoming(new ShippingArrange($order->address)); + } +} +``` + +## Design Principles + +Choose metamorphosis patterns according to the natural flow of domain logic: -Choose patterns based on your domain's natural flow: +- **Don't Force**: Don't force into artificial patterns +- **Keep Simple**: Choose the most simple and understandable form +- **Testable**: Each metamorphosis stage can be tested independently +- **Type Safe**: Next type is guaranteed by `#[Be()]` -- **Linear**: Sequential processes (validation → processing → completion) -- **Conditional Branching**: Decision points (approve/reject, success/failure, permission levels) -- **Nested**: Complex operations with sub-processes +Objects govern their own metamorphosis. -The key is to let transformation emerge naturally from the domain's flow, not force it into artificial patterns. +Heraclitus said "the river flows" is not correct, but rather "the flowing is the river." He believed that existence cannot be separated from change. Be Framework likewise believes that to capture essence, domain and time cannot be separated. +Domains are temporal existence. There are possibilities and being at each moment. Capturing how input classes, being classes, and final objects naturally metamorphose along the flow of time is the core of the Be Framework. diff --git a/manuals/1.0/ja/05-metamorphosis-patterns.md b/manuals/1.0/ja/05-metamorphosis-patterns.md index d1e81f1..2a256ba 100644 --- a/manuals/1.0/ja/05-metamorphosis-patterns.md +++ b/manuals/1.0/ja/05-metamorphosis-patterns.md @@ -1,46 +1,46 @@ --- layout: docs-ja -title: "5. 倉容パタヌン" +title: "5. メタモルフォヌシス" category: Manual -permalink: /manuals/1.0/ja/05-metamorphosis-patterns.html +permalink: /manuals/1.0/ja/05-metamorphosis.html --- -# 倉容パタヌン +# メタモルフォヌシス -> 「同じ川に二床入るこずはできない」 +> 「空間ず時間は独立に定矩できない」 > -> 　　—ヘラクレむトス『断片』玀元前500幎頃 +> 　　—アルベルト・アむンシュタむン『䞀般盞察性理論の基瀎』1916幎 -## 倉容の流れ +## 時間ずドメむンは分割できない -Beフレヌムワヌクは、単玔な線圢チェヌンから耇雑な分岐たで、様々な倉容パタヌンをサポヌトしたす。これらのパタヌンを理解するこずで、自然な倉容フロヌを蚭蚈できたす。 +アむンシュタむンが時間ず空間の䞍可分性を発芋したように、Beフレヌムワヌクでは時間ずドメむンは分割できない䞀぀の実䜓です。承認プロセスには承認の時間が、決枈には決枈の時間があり、それぞれのドメむンロゞックが持぀固有の時間軞に沿っお倉容が自然に珟れたす。 -## 線圢倉容チェヌン +## 䞍可逆的時間の流れ -最もシンプルなパタヌンA → B → C → D +オブゞェクトの倉容は時間の矢に沿った䞀方向の流れです。過去に戻るこずも、同じ瞬間に留たるこずもできたせん ```php -// 入力 +// 時間 T0: 入力の誕生 #[Be(EmailValidation::class)] final class EmailInput { /* ... */ } -// 第䞀倉容 +// 時間 T1: 第䞀倉容T0は既に過去 #[Be(UserCreation::class)] final class EmailValidation { /* ... */ } -// 第二倉容 +// 時間 T2: 第二倉容T1は蚘憶ずなる #[Be(WelcomeMessage::class)] final class UserCreation { /* ... */ } -// 最終結果 +// 時間 T3: 最終存圚すべおの過去を内包 final class WelcomeMessage { /* ... */ } ``` -各段階は自然に次ぞず導かれ、川が海に流れるようです。 +各瞬間は二床ず戻らず、新しい存圚は前の圢態をその内郚に蚘憶ずしお保持したす。川が流れるように、時間は䞀方向にのみ流れたす。 -## 条件分岐パタヌン +## 運呜の自己決定 -オブゞェクトはその性質に基づいお耇数の可胜な未来を持぀こずができたす。これは条件によっお異なる型ぞず分岐する自然な倉容です +珟実の生物ず同様に、オブゞェクトは内圚的な性質ず倖郚環境の盞互䜜甚によっお、自身の運呜を決定したす。これは予め決められたルヌトを蟿るのではなく、その瞬間の状況に応じた自然な倉容です ```php #[Be([ApprovedApplication::class, RejectedApplication::class])] @@ -49,11 +49,12 @@ final class ApplicationReview public readonly ApprovedApplication|RejectedApplication $being; public function __construct( - #[Input] array $documents, // 内圚的 - #[Inject] ReviewService $reviewer // 超越的 + #[Input] array $documents, // 内圚的性質 + #[Inject] ReviewService $reviewer // 倖郚環境 ) { $result = $reviewer->evaluate($documents); + // 運呜は今この瞬間に決たる $this->being = $result->isApproved() ? new ApprovedApplication($documents, $result->getScore()) : new RejectedApplication($result->getReasons()); @@ -61,31 +62,6 @@ final class ApplicationReview } ``` -### 他の条件分岐䟋 - -機胜レベルや暩限による分岐も同様のパタヌンです - -```php -#[Be([PremiumFeatures::class, BasicFeatures::class])] -final class FeatureActivation -{ - public readonly PremiumFeatures|BasicFeatures $being; - - public function __construct( - #[Input] User $user, // 内圚的 - #[Inject] SubscriptionService $service // 超越的 - ) { - $subscription = $service->getSubscription($user); - - $this->being = $subscription->isPremium() - ? new PremiumFeatures($user, $subscription) - : new BasicFeatures($user); - } -} -``` - -オブゞェクトは**型駆動倉容**を通しお自身の運呜を決定したす。 - ## ネストした倉容 @@ -148,12 +124,74 @@ match (true) { - 䟝存性泚入による胜力の提䟛 - テスト可胜な独立したコンポヌネント -## パタヌンの遞択 +## 実装䞊の遞択指針 + +### い぀線圢倉容を遞ぶか + +シヌケンシャルな凊理で、各段階が次に必芁なデヌタを準備する堎合 + +```php +ナヌザヌ登録 → メヌル怜蚌 → アカりント有効化 → りェルカム通知 +``` + +各段階での倱敗は党䜓を停止させる必芁がある堎合に適しおいたす。 + +### い぀条件分岐を遞ぶか + +同じ入力から性質や暩限によっお異なる結果に分岐する堎合 + +```php +// 実装䟋支払い胜力による機胜差 +#[Be([FullAccess::class, LimitedAccess::class, ReadOnlyAccess::class])] +final class AccessDetermination +{ + public readonly FullAccess|LimitedAccess|ReadOnlyAccess $being; + + public function __construct( + #[Input] User $user, + #[Inject] PaymentStatus $payment + ) { + $this->being = match($payment->getStatus()) { + 'premium' => new FullAccess($user, $payment->getFeatures()), + 'basic' => new LimitedAccess($user, $payment->getLimits()), + default => new ReadOnlyAccess($user) + }; + } +} +``` + +### い぀ネストした倉容を遞ぶか + +耇数の独立した凊理を䞊行しお実行し、それぞれの結果を集玄する堎合 + +```php +final class OrderCompletion +{ + public function __construct( + #[Input] OrderData $order, + #[Inject] Becoming $becoming + ) { + // 独立した凊理を䞊行実行 + $this->inventory = $becoming(new InventoryCheck($order->items)); + $this->payment = $becoming(new PaymentProcess($order->payment)); + $this->shipping = $becoming(new ShippingArrange($order->address)); + } +} +``` + +## 蚭蚈原則 + +倉容パタヌンの遞択は、ドメむンロゞックの自然な流れに埓っおください + +- **匷制しない**: 人工的なパタヌンに無理やり圓おはめない +- **シンプルに**: 最も単玔で理解しやすい圢を遞ぶ +- **テスト可胜**: 各倉容段階が独立しおテストできる +- **型安党**: `#[Be()]` によっお次の型が保蚌される + +オブゞェクトは自らが自らの倉容を芏定したす。 + +ヘラクレむトスは『川が流れおいる』のではなく『流れおいるのが川だ』ず蚀いたした。存圚は倉化ずは切り離せないず考えたのです。Be Frameworkも同じように本質を捉えるためにはドメむンず時間は切り離せないものず考えたした。 +ドメむンは時間的存圚です。その時その時の可胜性ず存圚がありたす。入力クラス、存圚クラス、最終オブゞェクトが時間の流れに沿っお自然に倉容しおいく様を捉えるこずが、Beフレヌムワヌクの栞心です。 -ドメむンの自然な流れに基づいおパタヌンを遞択しおください -- **線圢**: 順次プロセス怜蚌 → 凊理 → 完了 -- **条件分岐**: 決定ポむント承認/拒吊、成功/倱敗、暩限レベル -- **ネストした**: サブプロセスを持぀耇雑な操䜜 -重芁なのは、倉容をドメむンの自然な流れから生たれさせるこずであり、人工的なパタヌンに匷制するこずではありたせん。 From 2306a31b8579878a3c5c9b8d5eee4815a54125e8 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 16:32:45 +0900 Subject: [PATCH 10/12] Complete semantic variables concept integration in Japanese Chapter 6 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Key enhancements: - Replace abstract introduction with practical problem/solution structure - Add semantic completeness concept explaining distributed vs integrated approach - Include hierarchical validation with concrete business examples - Introduce relationship constraints with automatic pattern matching - Transform final section from bullet points to flowing philosophical prose - Strengthen the core principle: "Names are identifiers of meaning and constraints" 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- manuals/1.0/ja/06-semantic-variables.md | 166 +++++++++++++++++++----- 1 file changed, 133 insertions(+), 33 deletions(-) diff --git a/manuals/1.0/ja/06-semantic-variables.md b/manuals/1.0/ja/06-semantic-variables.md index 8a337c8..cf32eab 100644 --- a/manuals/1.0/ja/06-semantic-variables.md +++ b/manuals/1.0/ja/06-semantic-variables.md @@ -7,35 +7,49 @@ permalink: /manuals/1.0/ja/06-semantic-variables.html # 意味倉数 -> 「存圚すべきものは有効でなければなりたせん。存圚できないものは決しお生たれるこずはありたせん。」 +> 「存圚するものは必然的に存圚し、存圚しないものは必然的に存圚しない」 +> +> 　　—スピノザ『゚チカ』第1郚定理291677幎 -意味倉数はBeフレヌムワヌクの最も深い原理を䜓珟したす**意味のある存圚のみが存圚できる**。 +デヌタの劥圓性はどこで保蚌されるべきでしょうかコントロヌラヌモデルバリデヌタヌ -## 問題 +Be Frameworkの答えは明確です**名前そのものが制玄を持぀べき**ず考えたす。 +`$email`は単なる文字列ではなく、**有効なメヌルアドレス**であるべきです。`$age`にはマむナスの倀は存圚できたせん。 -埓来の型は無意味なものから守りたす +意味倉数は、情報の識別子であり、意味を衚し、制玄を持぀**完党な情報モデル**です。 + +## 問題分散した䞍完党性 + +埓来のアプロヌチでは、意味の定矩が散圚しおいたす ```php -function createUser(string $name, string $email, int $age) { - if (empty($name)) throw new Exception(); - if (!filter_var($email, FILTER_VALIDATE_EMAIL)) throw new Exception(); - // ... 無限の防埡的プログラミング -} +// コントロヌラヌ/model/validator... +if (empty($name)) throw new Exception("error.name.empty"); +if (!filter_var($email, FILTER_VALIDATE_EMAIL)) throw new Exception("error.email.invalid"); + +// messages/ja.yml +error.name.empty: "名前を入力しおください" +error.email.invalid: "有効なメヌルアドレスを入力しおください" + +// README.md +// "名前は1-100文字で空癜のみは䞍可..." ``` -## 解決法 +以䞋の問題が発生したす +- **バリデヌション**コントロヌラヌに散圚 +- **゚ラヌメッセヌゞ**別ファむルで管理 +- **制玄ルヌル**耇数の堎所に重耇 +- **意味定矩**ドキュメントにのみ存圚 -意味倉数は「これは有効ですか」から「これは存圚できたすか」ぞず根本的な問いを倉えたす。 +システムが扱う意味を集䞭しお芋るこずのできる堎所がありたせん。 -```php -function createUser(PersonName $name, EmailAddress $email, Age $age) { - // ここに到達すれば、存圚は既に保蚌されおいたす -} -``` +## 解決法意味的完党性 + +Be Frameworkは、分散した定矩を**完党な情報モデル**ずしお統合したす。コンストラクタの匕数やクラスのプロパティには、登録された**意味倉数**のみを䜿甚できたす。 ## 存圚の定矩 -すべおの意味倉数はそのドメむンで䜕が存圚できるかを定矩したす +意味倉数は専甚フォルダにクラスずしお定矩されたす ```php final class Name @@ -50,25 +64,45 @@ final class Name } ``` -耇数の怜蚌コンテキストが自然に存圚したす +## 怜蚌コンテキスト + +異なるビゞネスコンテキストには異なるルヌルが適甚されるこずがありたす。意味倉数は耇数の怜蚌コンテキストを自然にサポヌトしたす ```php final class ProductCode { #[Validate] - public function validate(string $code): void { /* 暙準ルヌル */ } + public function validate(string $code): void + { + // 暙準的な商品コヌド怜蚌䟋8桁の英数字 + if (!preg_match('/^[A-Z0-9]{8}$/', $code)) { + throw new InvalidProductCodeException(); + } + } #[Validate] - public function validateLegacy(#[Legacy] string $code): void { /* レガシヌルヌル */ } + public function validateLegacy(#[Legacy] string $code): void + { + // レガシヌシステム甚の緩い怜蚌䟋6-10桁の英数字 + if (!preg_match('/^[A-Z0-9]{6,10}$/', $code)) { + throw new InvalidLegacyProductCodeException(); + } + } #[Validate] - public function validatePremium(#[Premium] string $code): void { /* プレミアムルヌル */ } + public function validatePremium(#[Premium] string $code): void + { + // プレミアム商品甚の厳栌な怜蚌䟋特定のプレフィックス必須 + if (!preg_match('/^PREM[A-Z0-9]{4}$/', $code)) { + throw new InvalidPremiumProductCodeException(); + } + } } ``` -## 意味のある倱敗 +## 倱敗の意味 -存圚が倱敗したずき、意味は保持されなければなりたせん +存圚が倱敗したずき、倱敗の意味が保持されなければなりたせん ```php #[Message([ @@ -78,18 +112,18 @@ final class ProductCode final class EmptyNameException extends DomainException {} ``` -フレヌムワヌクは投げる前に**すべおの怜蚌゚ラヌ**を収集し、䜕が存圚できないかの完党な理解を䜜り出したす。 +フレヌムワヌクは最初に投げられる䟋倖だけでなく、**すべおの怜蚌゚ラヌ**を䟋倖の集合ずしお収集し、なぜ存圚できないかの完党な理解を䜜り出したす。 ## 自然な統合 -意味倉数は存圚コンストラクタで自動的に動䜜したす +意味倉数はコンストラクタで自動的に動䜜したす ```php final readonly class UserProfile { public function __construct( #[Input] #[English] public string $name, // 英語名ずしお自動怜蚌 - #[Input] string $emailAddress, // メヌルずしお自動怜蚌 + #[Input] string $emailAddress, // メヌルアドレスずしお自動怜蚌 #[Inject] NameFormatter $formatter ) { // この時点で、すべおの入力が有効であるこずが保蚌されおいたす @@ -97,9 +131,11 @@ final readonly class UserProfile } ``` +倉数名`$name`は`Name`意味倉数クラスず、`$emailAddress`は`EmailAddress`意味倉数クラスず自動的に関連付けられたす。 + ## 階局的怜蚌 -意味倉数は互いに構築できたす +意味倉数は他の意味倉数を基盀ずしお構築できたす。これはビゞネスルヌルの自然な階局構造を型システムで衚珟する匷力な手法です。 ```php final class TeenAge @@ -107,13 +143,68 @@ final class TeenAge #[Validate] public function validate(#[Teen] int $age): void { - // 基本的なAge怜蚌を継承し、ティヌン固有のルヌルを远加 + // たず基本的なAge怜蚌が実行される#[Teen]により自動的に呌び出される + // その埌、ティヌン固有のルヌルを远加 if ($age < 13) throw new TeenAgeTooYoungException(); if ($age > 19) throw new TeenAgeTooOldException(); } } ``` +この階局的アプロヌチにより、豊かな意味の階局が構築されたす + +- `Email` → `CorporateEmail`䌁業ドメむン必須→ `ExecutiveEmail`圹員レベルの制玄 +- `Price` → `DiscountPrice`割匕率制限→ `MemberPrice`䌚員特䟡ルヌル +- `Password` → `AdminPassword`管理者芁件→ `SystemPassword`システム管理者の厳栌芁件 +- `Address` → `ShippingAddress`配送可胜地域→ `InternationalAddress`囜際配送察応 + +各階局は前の局の制玄を継承し、さらに固有の制玄を远加したす。基本的な`Email`怜蚌が通らないものは、決しお`ExecutiveEmail`ずしお存圚できたせん。これは単なる怜蚌の組み合わせではなく、**抂念の自然な粟緻化**です。 + +## 関係性制玄 + +意味倉数は単独で存圚するだけでなく、他の意味倉数ずの関係性も制玄ずしお持おたす。特筆すべきは**その蚘述の容易さ**です + +```php +final readonly class UserRegistration +{ + public function __construct( + #[Input] string $email, + #[Input] string $confirmEmail, + #[Input] string $password, + #[Input] string $confirmPassword, + ) { + // 䜕も曞く必芁はありたせん + // フレヌムワヌクが自動的に関係性を怜蚌したす + } +} +``` + +フレヌムワヌクは、察象のコンストラクタのシグネチャず**郚分マッチ**する怜蚌クラスを自動的に発芋し、適甚したす。 + +```php +// これがあれば... +final class EmailConfirmation +{ + #[Validate] + public function validate(string $email, string $confirmEmail): void + { + if ($email !== $confirmEmail) { + throw new EmailMismatchException(); + } + } +} + +// $email, $confirmEmail を持぀任意のコンストラクタで自動適甚される +``` + +関係性制玄の䟋 +- `$startDate` ず `$endDate`開始日は終了日より前でなければならない +- `$minPrice` ず `$maxPrice`最小䟡栌は最倧䟡栌以䞋でなければならない +- `$email` ず `$confirmEmail`メヌルアドレスの確認䞀臎が必芁 +- `$currentPassword` ず `$newPassword`新しいパスワヌドは珟圚のものず異なる必芁 + +開発者はビゞネスルヌルを䞀床定矩するだけで、該圓するシグネチャを持぀党おのオブゞェクトで自動的に適甚されたす。これらの制玄は、オブゞェクトが存圚する**前提条件**ずしお機胜したす。前提が満たされない限り、そのオブゞェクトは存圚するこずすらできたせん。 + ## ゚ラヌハンドリング 倚蚀語゚ラヌメッセヌゞは自動的に適応したす @@ -127,13 +218,16 @@ try { } ``` -## 革呜 +## 意味がもたらすもの + +**名前は、意味、制玄の識別子です。**この単玔な原理だけで、フレヌムワヌクずいえるほどの豊かな䞖界が実珟されたす。 + +意味倉数により、**䞍可胜な状態が䞍可胜になりたす**。無効なメヌルアドレスは`$email`ずしお存圚できず、負の幎霢は`$age`ずしお生たれるこずすらありたせん。圚庫のない商品は`$orderId`ずしお泚文されるこずなく、東京23区倖の䜏所は`$city`ずしお配送先に指定されるこずもありたせん。 -意味倉数は**䞍可胜な状態を䞍可胜にする**こずで防埡的プログラミングを排陀したす。 +型システムそのものが**ドメむン蚀語**ずなり、各型があなたのビゞネスドメむンで䜕が存圚可胜かを語りたす。 -型システムは**ドメむン蚀語**になりたす—各型があなたのビゞネスドメむンで䜕が存圚できるかの意味を運びたす。 +関数シグネチャを芋れば、それが仕様曞になりたす -関数シグネチャは**ドキュメント**になりたす ```php function processOrder(ProductCode $product, PaymentAmount $amount, CustomerAge $age) { @@ -141,8 +235,14 @@ function processOrder(ProductCode $product, PaymentAmount $amount, CustomerAge $ } ``` +この関数は有効な商品コヌド、正の金額、有効な幎霢のみを受け入れたす。ドキュメントを読む必芁はありたせん—型が党おを物語っおいたす。 + +防埡的プログラミングは䞍芁になりたす。匕数の怜蚌、null チェック、範囲確認、圚庫確認、地理的制玄—これらはすべお意味倉数が保蚌したす。コヌドは本来の目的であるビゞネスロゞックの実装に集䞭できるのです。 + +単なる呜名芏玄から始たった抂念が、階局的怜蚌、関係性制玄、倖郚リ゜ヌス統合たで発展し、完党なドメむン保蚌システムを構築したす。**名前に蟌められた意味が、システム党䜓の敎合性を支えるのです。** + --- **次ぞ**: オブゞェクトが自身の性質を発芋する[型駆動倉容](07-type-driven-metamorphosis.html)に぀いお孊びたしょう。 -*「意味倉数はデヌタを怜蚌するだけでなく、意味のある存圚のみが存圚できるこずを保蚌したす。」* \ No newline at end of file +*「意味倉数はデヌタを怜蚌するだけでなく、意味のある存圚のみが存圚できるこずを保蚌したす。」* From 7e8c8c8f6d05a65f795b6b088892e7dfdf7c0983 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 16:43:27 +0900 Subject: [PATCH 11/12] Complete semantic variables concept integration in English Chapter 6 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Key enhancements: - Replace abstract introduction with practical problem/solution structure using Spinoza quote - Add semantic completeness concept explaining distributed vs integrated approach - Include hierarchical validation with concrete business examples and natural refinement - Introduce relationship constraints with automatic pattern matching capabilities - Transform final section from bullet points to flowing philosophical prose - Strengthen the core principle: "Names are identifiers of meaning and constraints" - Add validation contexts section with detailed business rule examples 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- manuals/1.0/en/06-semantic-variables.md | 166 +++++++++++++++++++----- 1 file changed, 133 insertions(+), 33 deletions(-) diff --git a/manuals/1.0/en/06-semantic-variables.md b/manuals/1.0/en/06-semantic-variables.md index 909bd66..cb07461 100644 --- a/manuals/1.0/en/06-semantic-variables.md +++ b/manuals/1.0/en/06-semantic-variables.md @@ -7,35 +7,49 @@ permalink: /manuals/1.0/en/06-semantic-variables.html # Semantic Variables -> "What should exist must be valid. What cannot exist will never be born." +> "What exists necessarily exists, and what does not exist necessarily does not exist" +> +> 　　—Spinoza, *Ethics*, Part I, Proposition 29 (1677) -Semantic Variables embody Be Framework's deepest principle: **only meaningful beings can exist**. +Where should data validity be guaranteed? Controller? Model? Validator? -## The Problem +Be Framework's answer is clear: **names themselves should carry constraints**. +`$email` should not be just a string—it should be a **valid email address**. `$age` cannot have negative values. -Traditional types defend against the meaningless: +Semantic Variables are identifiers of information that express meaning and hold constraints—they are **complete information models**. + +## The Problem: Scattered Incompleteness + +Traditional approaches scatter the definition of meaning across multiple locations: ```php -function createUser(string $name, string $email, int $age) { - if (empty($name)) throw new Exception(); - if (!filter_var($email, FILTER_VALIDATE_EMAIL)) throw new Exception(); - // ... endless defensive programming -} +// Controllers/models/validators... +if (empty($name)) throw new Exception("error.name.empty"); +if (!filter_var($email, FILTER_VALIDATE_EMAIL)) throw new Exception("error.email.invalid"); + +// messages/en.yml +error.name.empty: "Name is required" +error.email.invalid: "Please enter a valid email address" + +// README.md +// "Name must be 1-100 characters, whitespace-only not allowed..." ``` -## The Solution +The following problems occur: +- **Validation**: Scattered across controllers +- **Error messages**: Managed in separate files +- **Constraint rules**: Duplicated in multiple places +- **Meaning definition**: Exists only in documentation -Semantic Variables change the fundamental question from "Is this valid?" to "Can this exist?" +There is no central place to see the meanings that the system handles. -```php -function createUser(PersonName $name, EmailAddress $email, Age $age) { - // If we reach here, existence is already guaranteed -} -``` +## The Solution: Semantic Completeness + +Be Framework integrates scattered definitions into **complete information models**. Constructor arguments and class properties can only use registered **semantic variables**. ## Defining Existence -Every semantic variable defines what can exist in its domain: +Semantic variables are defined as classes in dedicated folders: ```php final class Name @@ -50,25 +64,45 @@ final class Name } ``` -Multiple validation contexts exist naturally: +## Validation Contexts + +Different business contexts may require different rules. Semantic variables naturally support multiple validation contexts: ```php final class ProductCode { #[Validate] - public function validate(string $code): void { /* standard rules */ } + public function validate(string $code): void + { + // Standard product code validation (e.g., 8-digit alphanumeric) + if (!preg_match('/^[A-Z0-9]{8}$/', $code)) { + throw new InvalidProductCodeException(); + } + } #[Validate] - public function validateLegacy(#[Legacy] string $code): void { /* legacy rules */ } + public function validateLegacy(#[Legacy] string $code): void + { + // Relaxed validation for legacy systems (e.g., 6-10 digit alphanumeric) + if (!preg_match('/^[A-Z0-9]{6,10}$/', $code)) { + throw new InvalidLegacyProductCodeException(); + } + } #[Validate] - public function validatePremium(#[Premium] string $code): void { /* premium rules */ } + public function validatePremium(#[Premium] string $code): void + { + // Strict validation for premium products (e.g., specific prefix required) + if (!preg_match('/^PREM[A-Z0-9]{4}$/', $code)) { + throw new InvalidPremiumProductCodeException(); + } + } } ``` -## Meaningful Failure +## The Meaning of Failure -When existence fails, meaning must be preserved: +When existence fails, the meaning of failure must be preserved: ```php #[Message([ @@ -78,18 +112,18 @@ When existence fails, meaning must be preserved: final class EmptyNameException extends DomainException {} ``` -The framework collects **all validation errors** before throwing, creating complete understanding of what cannot exist. +The framework collects not just the first thrown exception but **all validation errors** as a collection of exceptions, creating complete understanding of why existence is impossible. ## Natural Integration -Semantic variables work automatically in Being constructors: +Semantic variables work automatically in constructors: ```php final readonly class UserProfile { public function __construct( #[Input] #[English] public string $name, // Auto-validated as English name - #[Input] string $emailAddress, // Auto-validated as email + #[Input] string $emailAddress, // Auto-validated as email address #[Inject] NameFormatter $formatter ) { // At this point, all inputs are guaranteed valid @@ -97,9 +131,11 @@ final readonly class UserProfile } ``` +The variable name `$name` is automatically associated with the `Name` semantic variable class, and `$emailAddress` with the `EmailAddress` semantic variable class. + ## Hierarchical Validation -Semantic variables can build upon each other: +Semantic variables can build upon other semantic variables. This is a powerful technique for expressing the natural hierarchical structure of business rules in the type system. ```php final class TeenAge @@ -107,13 +143,68 @@ final class TeenAge #[Validate] public function validate(#[Teen] int $age): void { - // Inherits basic Age validation, adds teen-specific rules + // First, basic Age validation is executed (automatically called via #[Teen]) + // Then, teen-specific rules are added if ($age < 13) throw new TeenAgeTooYoungException(); if ($age > 19) throw new TeenAgeTooOldException(); } } ``` +This hierarchical approach builds rich semantic hierarchies: + +- `Email` → `CorporateEmail` (corporate domain required) → `ExecutiveEmail` (executive-level constraints) +- `Price` → `DiscountPrice` (discount rate limits) → `MemberPrice` (member pricing rules) +- `Password` → `AdminPassword` (admin requirements) → `SystemPassword` (strict system admin requirements) +- `Address` → `ShippingAddress` (deliverable regions) → `InternationalAddress` (international shipping support) + +Each layer inherits constraints from the previous layer and adds its own unique constraints. Nothing that fails basic `Email` validation can ever exist as `ExecutiveEmail`. This is not merely a combination of validations—it is the **natural refinement of concepts**. + +## Relationship Constraints + +Semantic variables exist not only in isolation but can also hold relationships with other semantic variables as constraints. What's remarkable is **how easy this is to describe**: + +```php +final readonly class UserRegistration +{ + public function __construct( + #[Input] string $email, + #[Input] string $confirmEmail, + #[Input] string $password, + #[Input] string $confirmPassword, + ) { + // Nothing needs to be written here! + // The framework automatically validates relationships + } +} +``` + +The framework automatically discovers and applies validation classes that **partially match** the target constructor's signature. + +```php +// If this exists... +final class EmailConfirmation +{ + #[Validate] + public function validate(string $email, string $confirmEmail): void + { + if ($email !== $confirmEmail) { + throw new EmailMismatchException(); + } + } +} + +// It's automatically applied to any constructor with $email, $confirmEmail! +``` + +Examples of relationship constraints: +- `$startDate` and `$endDate`: Start date must be before end date +- `$minPrice` and `$maxPrice`: Minimum price must be less than or equal to maximum price +- `$email` and `$confirmEmail`: Email address confirmation match required +- `$currentPassword` and `$newPassword`: New password must differ from current one + +Developers define business rules once, and they're automatically applied to all objects with matching signatures. These constraints function as **preconditions** for object existence. Unless preconditions are met, that object cannot even exist. + ## Error Handling Multilingual error messages adapt automatically: @@ -127,13 +218,16 @@ try { } ``` -## The Revolution +## What Meaning Brings + +**Names are identifiers of meaning and constraints.** This simple principle alone realizes a world rich enough to be called a framework. + +Semantic Variables make **impossible states impossible**. Invalid email addresses cannot exist as `$email`, negative ages cannot be born as `$age`. Out-of-stock products cannot be ordered as `$orderId`, and addresses outside delivery zones cannot be specified as `$shippingAddress`. -Semantic Variables eliminate defensive programming by making **impossible states impossible**. +The type system itself becomes a **domain language**, where each type speaks of what can exist in your business domain. -The type system becomes a **domain language**—each type carries the meaning of what can exist in your business domain. +Looking at function signatures, they become specifications: -Function signatures become **documentation**: ```php function processOrder(ProductCode $product, PaymentAmount $amount, CustomerAge $age) { @@ -141,8 +235,14 @@ function processOrder(ProductCode $product, PaymentAmount $amount, CustomerAge $ } ``` +This function accepts only valid product codes, positive amounts, and valid ages. No need to read documentation—the types tell the whole story. + +Defensive programming becomes unnecessary. Argument validation, null checks, range verification, inventory confirmation, geographic constraints—semantic variables guarantee all of these. Code can focus on its true purpose: implementing business logic. + +What began as a simple naming convention evolves into hierarchical validation, relationship constraints, external resource integration, building a complete domain guarantee system. **The meaning embedded in names supports the integrity of the entire system.** + --- -**Next**: Learn about [Type-Driven Metamorphosis](06-type-driven-metamorphosis.md) where objects discover their own nature. +**Next**: Learn about [Type-Driven Metamorphosis](07-type-driven-metamorphosis.html) where objects discover their own nature. *"Semantic Variables don't just validate data—they ensure only meaningful beings can exist."* From 6a89f1ff38a4781f838a718e00b12d2ca70ec633 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 12 Sep 2025 17:09:14 +0900 Subject: [PATCH 12/12] Fix metamorphosis chapter slug references and unify terminology MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Update index links in both languages to use new slug: 05-metamorphosis.html - Unify English terminology: "Immanent/Transcendent" → "Intrinsic nature/External environment" - Ensure consistency across all metamorphosis pattern examples - Remove outdated 05-metamorphosis-patterns.html references 🀖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- manuals/1.0/en/05-metamorphosis-patterns.md | 4 ++-- manuals/1.0/en/index.md | 2 +- manuals/1.0/ja/index.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/manuals/1.0/en/05-metamorphosis-patterns.md b/manuals/1.0/en/05-metamorphosis-patterns.md index 8568e29..2a3afba 100644 --- a/manuals/1.0/en/05-metamorphosis-patterns.md +++ b/manuals/1.0/en/05-metamorphosis-patterns.md @@ -75,8 +75,8 @@ final class OrderProcessing public readonly ShippingResult $shipping; public function __construct( - #[Input] Order $order, // Immanent - #[Inject] Becoming $becoming // Transcendent + #[Input] Order $order, // Intrinsic nature + #[Inject] Becoming $becoming // External environment ) { // Nested transformations $this->payment = $becoming(new PaymentInput($order->getPayment())); diff --git a/manuals/1.0/en/index.md b/manuals/1.0/en/index.md index c5fec09..cdbfb37 100644 --- a/manuals/1.0/en/index.md +++ b/manuals/1.0/en/index.md @@ -21,7 +21,7 @@ Intermediate transformations through Immanent + Transcendent interactions ## [4. Final Objects](04-final-objects.html) The destination of metamorphosis - complete transformed beings -## [5. Metamorphosis Patterns](05-metamorphosis-patterns.html) +## [5. Metamorphosis Patterns](05-metamorphosis.html) Simple chains, branching destinies, and complex transformations ## [6. Semantic Variables](06-semantic-variables.html) diff --git a/manuals/1.0/ja/index.md b/manuals/1.0/ja/index.md index 5f231ef..4571b2c 100644 --- a/manuals/1.0/ja/index.md +++ b/manuals/1.0/ja/index.md @@ -20,7 +20,7 @@ permalink: /manuals/1.0/ja/ ## [4. 最終オブゞェクト](04-final-objects.html) 倉容の目的地 - 完党に倉容した存圚 -## [5. 倉容パタヌン](05-metamorphosis-patterns.html) +## [5. 倉容パタヌン](05-metamorphosis.html) 単玔な連鎖、分岐する運呜、耇雑な倉容 ## [6. 意味倉数](06-semantic-variables.html)