From 9e70e04b85a867fa38775fabefeb24d906a4010a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fran=C3=A7ois=20Marie=20De=20Mey?= Date: Sat, 2 Nov 2024 15:26:21 +0200 Subject: [PATCH] typos --- README.md | 24 +++++++++++++----------- package.json | 2 +- src/seclude.ts | 3 ++- 3 files changed, 16 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index eef91ec..138d891 100644 --- a/README.md +++ b/README.md @@ -131,9 +131,9 @@ class X4 { ... } class D2 extends D(X1, X3, D1, X4, X2) ``` -Here, the flat legacy od `D2` will be `D1 - X1 - X3 - X2 - X4`. The fact that `D1` specifies it inherits from `X1` is promised to be kept, the order in the arguments is surely going to happen if the situation is not too complex. +Here, the flat legacy of `D2` will be `D1 - X1 - X3 - X2 - X4`. The fact that `D1` specifies it inherits from `X1` is promised to be kept, the order in the arguments is surely going to happen if the situation is not too complex. -A real order conflict would imply circular reference who is any impossible. +A real order conflict would imply circular reference who is impossible. ### Dealing with non-`Diamond`-ed classes @@ -158,6 +158,8 @@ The only problem still worked on is that if a class who has no implementation fo > :arrow_up: Btw, if someone could help me here... It's on `HasBases` type definition +> Note: [It seems impossible...](https://stackoverflow.com/questions/79149281/complex-types-definition-abstract-method-filter) + ### Construction concern The main concern is about the fact that a class can think it extends directly another and another class can "come" in between in some legacy schemes. It is mainly concerning for constructors. @@ -221,11 +223,11 @@ import D, { constructedObject } from 'flat-diamond' # Seclusion -Another big deal of diamond inheritance is field conflicts. +Another big deal of diamond inheritance is field and method conflicts. ## Easy case -You write all the classes and, when remembering a `wingSpan`, you know that a plane is not a duck. You either have a plane wit a duck inside (property) or a duck that imitates a plane - but you don't confuse your `wingSpan`s. +You write all the classes and, when storing a `wingSpan`, you know that a plane is not a duck. You either have a plane wit a duck inside (property) or a duck that imitates a plane - but you don't confuse your `wingSpan`s. Don't make field conflicts. Just don't. @@ -233,7 +235,7 @@ Don't make field conflicts. Just don't. Here it is tricky, and that's where _seclusion_ comes in. Let's speak about seclusion without speaking of diamond - and, if you wish, the seclusion works without the need of involving `Diamond`. (though it is also completely integrated) -Let's say we want a `DuckCourier` to implement `Plane`, and end up with a conflict of `wingSpan` (the one of the duck and the one of the device strapped on him, the `Plane` one) +Let's say we want a `DuckCourier` to implement `Plane`, and end up with a conflict of `wingSpan` (the one of the duck and the one of the device mounted him, the `Plane` one) A pure and simple `class DuckCourier extends Plane` would have a field conflict. So, instead, seclusion will be used : @@ -247,7 +249,7 @@ As simple as that, methods (as well as accessors) of `Plane` and `DuckCourier` w ## But ... How ? And, how can I ... -When a secluded class is implemented, the `Plane` instance prototype will be replaced by `this` (so, here, a `DuckCourier`) mixed with some `Proxy` voodoo to manage who is `this` in method/accessor calls (either `DuckCourier` or `Secluded`) - et voilà! +When a secluded class is implemented (here, a `Plane`), the instance prototype will be replaced by `this` (so, here, a `DuckCourier`) mixed with some `Proxy` voodoo to manage who is `this` in method/accessor calls (either `DuckCourier` or `Secluded`) - et voilà! Because of prototyping, `Secluded` has access to all the functionalities of `DuckCourier` (and therefore of `Plane`) while never interfering with `DuckCourier::wingSpan`. Also, having several secluded class in the legacy list will only create several "heads" who will share a prototype. @@ -270,11 +272,13 @@ class DuckCourier extends MountedPlane { } ``` -## Seclusion and construction +## Seclusion and... + +### ...construction -The `Secluded` will indeed be the object the `Plane` constructor built! If it was used in the references, it's perfect! +The `Secluded` will indeed be the object the `Plane` constructor built! If `this` was used as a reference to have globally in the constructor, it's perfect, as it will also be the object it will have as `this` in his method calls. -## Secluding instance methods +### ...instance methods Yes, it's okay... @@ -283,5 +287,3 @@ So, secluding can also be useful when some class specify different methods with # Participation The best (even if not only) way to report a bug is to PR a failing unit test. - -I have been really struggling with the [`HasBases` issue](#abstraction) and didn't find a way to detect in Typescript types definition if a method is abstract or not - if someone has an idea. diff --git a/package.json b/package.json index 540839e..7f40043 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "flat-diamond", - "version": "1.0.4", + "version": "1.0.6", "types": "./lib/index.d.ts", "exports": { ".": { diff --git a/src/seclude.ts b/src/seclude.ts index f0a0d22..3339f4a 100644 --- a/src/seclude.ts +++ b/src/seclude.ts @@ -59,7 +59,6 @@ export function Seclude