Merge branch 'master' into pub

Author: FatulM

.tools/all

@@ -6,12 +6,12 @@
 .tools/init || exit 1
 .tools/fix || exit 1
 .tools/format || exit 1
-.tools/analyze || exit 1
 .tools/build || exit 1
 .tools/cpex || exit 1
 .tools/test || exit 1
 .tools/coverage || exit 1
 .tools/example || exit 1
+.tools/analyze || exit 1
 
 git add .
 git status

.tools/all.bat

@@ -6,12 +6,12 @@ call .tools\cprm || exit 1
 call .tools\init || exit 1
 call .tools\fix || exit 1
 call .tools\format || exit 1
-call .tools\analyze || exit 1
 call .tools\build || exit 1
 call .tools\cpex || exit 1
 call .tools\test || exit 1
 call .tools\coverage || exit 1
 call .tools\example || exit 1
+call .tools\analyze || exit 1
 
 git add .
 git status

CHANGELOG.md

@@ -1,7 +1,12 @@
-## 1.0.0
+## 1.2.0
 
-- Initial version
+- Using factory instead of static methods
+- Disabled copy method generation
 
 ## 1.1.0
 
 - Decoupled super_enum APIs from dart_sealed
+
+## 1.0.0
+
+- Initial version

README.md

@@ -12,7 +12,7 @@ Generate sealed class hierarchy for Dart and Flutter, For null-safe and legacy p
 
 ## Features
 
-* Generate sealed class with abstract super type and data sub classes.
+* Generate sealed class with abstract super type and data sub-classes.
 * Static factory methods. for example `Result.success(data: 0)`.
 * Cast methods. for example `a.asSuccess()`, `a.isSuccess()` or `a.asSuccessOrNull()`.
 * Three types of equality and hashCode generation : data (like kotlin data classes), identity and distinct.
@@ -53,7 +53,7 @@ part 'weather.sealed.dart';
 Add `@Sealed` annotation, and an abstract private class as a manifest for generated code.
 
 You can choose between three types of equality using `@WithEquality(...)` annotation. Default equality is `data` if not
-specified. This will become default equality for all sub classes. You can change equality of each sub class by using
+specified. This will become default equality for all sub-classes. You can change equality of each sub-class by using
 this annotation on individual methods.
 
 Equality types:
@@ -92,14 +92,14 @@ abstract class _Weather {
 ```
 
 An abstract super class is generated with name equal to name of manifest class without the underline (here `Weather`).
-Each method will become a sub class. There should be at least one method. Sub class names are based on method name
+Each method will become a sub-class. There should be at least one method. sub-class names are based on method name
 prefixed with super class name (for example `WeatherSunny`). Naming process can be tailored with use of `@WithPrefix`
-and `@WithName` annotations. Each method argument will become a field in corresponding sub class. Field names are equal
+and `@WithName` annotations. Each method argument will become a field in corresponding sub-class. Field names are equal
 to argument names and field types are equal to argument types or dynamic if not specified. Argument types can be
 overridden using `@WithType` annotation for example when type information is not available at build time. Note that you
 can have nullable and non-nullable fields. In legacy projects all fields are considered nullable.
 
-To change prefix of sub class names which by default is top class name, you can use `@WithPrefix` annotation. for
+To change prefix of sub-class names which by default is top class name, you can use `@WithPrefix` annotation. for
 example:
 
 ```dart
@@ -111,9 +111,9 @@ abstract class _Weather {
 ```
 
 Now `sunny` will be named `HelloSunny` instead of the default `WeatherSunny`. You can use `@WithPrefix('')` to remove
-all prefix from sub class names.
+all prefix from sub-class names.
 
-To change sub class names directly you can use `@WithName` annotation. It will override `WithPrefix` if specified. for
+To change sub-class names directly you can use `@WithName` annotation. It will override `WithPrefix` if specified. for
 example:
 
 ```dart
@@ -124,11 +124,11 @@ abstract class _Weather {
 }
 ```
 
-Now `sunny` will be named `Hello` instead of the default `WeatherSunny`. This is use full if you want not to use prefix
+Now `sunny` will be named `Hello` instead of the default `WeatherSunny`. This is useful if you want not to use prefix
 for some items.
 
-Almost all methods on sealed classes use short names extracted from manifest method names. Full sub class names are not
-used. It is recommended not to use sub classes directly. There are factory methods for each item on super class.
+Almost all methods on sealed classes use short names extracted from manifest method names. Full sub-class names are not
+used. It is recommended not to use sub-classes directly. There are factory methods for each item on super class.
 
 Then run the following command to generate code for you.
 
@@ -140,8 +140,7 @@ The generated code will look like: (the following code is summarised)
 
 ```dart
 abstract class Weather {
-  static WeatherRainy rainy({required int rain}) =>
-      WeatherRainy(rain: rain);
+  factory Weather.rainy({required int rain}) = WeatherRainy;
 
   bool isRainy() => this is WeatherRainy;
 
@@ -213,9 +212,6 @@ class WeatherRainy extends Weather with EquatableMixin {
 
   final int rain;
 
-  WeatherRainy copy({int? rain}) =>
-      WeatherRainy(rain: rain ?? this.rain);
-
   @override
   String toString() => 'Weather.rainy(rain: $rain)';
 
@@ -231,7 +227,7 @@ class WeatherWindy extends Weather {
 Notes:
 
 - Always use exact match method that you need, for example do not use `whenOrNull` instead of `whenPartial`.
-- Prefer using factories in super class instead of sub class constructors.
+- Prefer using factories in super class instead of sub-class constructors.
 - Minimize usage of cast methods, most of the time they can be replaced with a match method.
 
 ## Generic Usage
@@ -276,7 +272,7 @@ abstract class _Result<D extends num, E extends Object> {
 ## Wrapping and Inheritance
 
 There are times when you are using a sealed type only to wrap some fields and then unwrap it by using match functions in
-for example your blocs. In these situations it is better for the sealed sub class not to appear explicitly.
+for example your blocs. In these situations it is better for the sealed sub-class not to appear explicitly.
 
 for example suppose the following manifest:
 
@@ -332,8 +328,8 @@ Object doTest(State s) {
 }
 ```
 
-As you see it automatically unwraps values for you. If you add `@WithWrap()` on class it will apply to all sub classes.
-If you want wrapping only for some of your sub classes apply them to methods. for example:
+As you see it automatically unwraps values for you. If you add `@WithWrap()` on class it will apply to all sub-classes.
+If you want wrapping only for some of your sub-classes apply them to methods. for example:
 
 ```dart
 @Sealed()
@@ -350,7 +346,7 @@ abstract class State {
 
 In previous example `data` will not be automatically unwrapped.
 
-Also, when making a sealed sub class wrapped, its constructor and the corresponding factory in sealed super class will
+Also, when making a sealed sub-class wrapped, its constructor and the corresponding factory in sealed super class will
 be using positional arguments instead of named arguments. For example for `data`:
 
 ```dart
@@ -408,7 +404,7 @@ For more information check `super_enum` documentation:
 
 ### migrating from super_enum
 
-If you were using super_enum and now you want to change your dependency to dart_sealed:
+If you were using super_enum, and now you want to change your dependency to dart_sealed:
 
 * Change dependency of `super_enum` with `super_enum_sealed_annotations`.
 * Add dependency to `sealed_annotations`.

sealed_annotations/CHANGELOG.md

@@ -1,7 +1,12 @@
-## 1.0.0
+## 1.2.0
 
-- Initial version
+- Using factory instead of static methods
+- Disabled copy method generation
 
 ## 1.1.0
 
 - Decoupled super_enum APIs from dart_sealed
+
+## 1.0.0
+
+- Initial version

sealed_annotations/README.md

@@ -12,7 +12,7 @@ Generate sealed class hierarchy for Dart and Flutter, For null-safe and legacy p
 
 ## Features
 
-* Generate sealed class with abstract super type and data sub classes.
+* Generate sealed class with abstract super type and data sub-classes.
 * Static factory methods. for example `Result.success(data: 0)`.
 * Cast methods. for example `a.asSuccess()`, `a.isSuccess()` or `a.asSuccessOrNull()`.
 * Three types of equality and hashCode generation : data (like kotlin data classes), identity and distinct.
@@ -53,7 +53,7 @@ part 'weather.sealed.dart';
 Add `@Sealed` annotation, and an abstract private class as a manifest for generated code.
 
 You can choose between three types of equality using `@WithEquality(...)` annotation. Default equality is `data` if not
-specified. This will become default equality for all sub classes. You can change equality of each sub class by using
+specified. This will become default equality for all sub-classes. You can change equality of each sub-class by using
 this annotation on individual methods.
 
 Equality types:
@@ -92,14 +92,14 @@ abstract class _Weather {
 ```
 
 An abstract super class is generated with name equal to name of manifest class without the underline (here `Weather`).
-Each method will become a sub class. There should be at least one method. Sub class names are based on method name
+Each method will become a sub-class. There should be at least one method. sub-class names are based on method name
 prefixed with super class name (for example `WeatherSunny`). Naming process can be tailored with use of `@WithPrefix`
-and `@WithName` annotations. Each method argument will become a field in corresponding sub class. Field names are equal
+and `@WithName` annotations. Each method argument will become a field in corresponding sub-class. Field names are equal
 to argument names and field types are equal to argument types or dynamic if not specified. Argument types can be
 overridden using `@WithType` annotation for example when type information is not available at build time. Note that you
 can have nullable and non-nullable fields. In legacy projects all fields are considered nullable.
 
-To change prefix of sub class names which by default is top class name, you can use `@WithPrefix` annotation. for
+To change prefix of sub-class names which by default is top class name, you can use `@WithPrefix` annotation. for
 example:
 
 ```dart
@@ -111,9 +111,9 @@ abstract class _Weather {
 ```
 
 Now `sunny` will be named `HelloSunny` instead of the default `WeatherSunny`. You can use `@WithPrefix('')` to remove
-all prefix from sub class names.
+all prefix from sub-class names.
 
-To change sub class names directly you can use `@WithName` annotation. It will override `WithPrefix` if specified. for
+To change sub-class names directly you can use `@WithName` annotation. It will override `WithPrefix` if specified. for
 example:
 
 ```dart
@@ -124,11 +124,11 @@ abstract class _Weather {
 }
 ```
 
-Now `sunny` will be named `Hello` instead of the default `WeatherSunny`. This is use full if you want not to use prefix
+Now `sunny` will be named `Hello` instead of the default `WeatherSunny`. This is useful if you want not to use prefix
 for some items.
 
-Almost all methods on sealed classes use short names extracted from manifest method names. Full sub class names are not
-used. It is recommended not to use sub classes directly. There are factory methods for each item on super class.
+Almost all methods on sealed classes use short names extracted from manifest method names. Full sub-class names are not
+used. It is recommended not to use sub-classes directly. There are factory methods for each item on super class.
 
 Then run the following command to generate code for you.
 
@@ -140,8 +140,7 @@ The generated code will look like: (the following code is summarised)
 
 ```dart
 abstract class Weather {
-  static WeatherRainy rainy({required int rain}) =>
-      WeatherRainy(rain: rain);
+  factory Weather.rainy({required int rain}) = WeatherRainy;
 
   bool isRainy() => this is WeatherRainy;
 
@@ -213,9 +212,6 @@ class WeatherRainy extends Weather with EquatableMixin {
 
   final int rain;
 
-  WeatherRainy copy({int? rain}) =>
-      WeatherRainy(rain: rain ?? this.rain);
-
   @override
   String toString() => 'Weather.rainy(rain: $rain)';
 
@@ -231,7 +227,7 @@ class WeatherWindy extends Weather {
 Notes:
 
 - Always use exact match method that you need, for example do not use `whenOrNull` instead of `whenPartial`.
-- Prefer using factories in super class instead of sub class constructors.
+- Prefer using factories in super class instead of sub-class constructors.
 - Minimize usage of cast methods, most of the time they can be replaced with a match method.
 
 ## Generic Usage
@@ -276,7 +272,7 @@ abstract class _Result<D extends num, E extends Object> {
 ## Wrapping and Inheritance
 
 There are times when you are using a sealed type only to wrap some fields and then unwrap it by using match functions in
-for example your blocs. In these situations it is better for the sealed sub class not to appear explicitly.
+for example your blocs. In these situations it is better for the sealed sub-class not to appear explicitly.
 
 for example suppose the following manifest:
 
@@ -332,8 +328,8 @@ Object doTest(State s) {
 }
 ```
 
-As you see it automatically unwraps values for you. If you add `@WithWrap()` on class it will apply to all sub classes.
-If you want wrapping only for some of your sub classes apply them to methods. for example:
+As you see it automatically unwraps values for you. If you add `@WithWrap()` on class it will apply to all sub-classes.
+If you want wrapping only for some of your sub-classes apply them to methods. for example:
 
 ```dart
 @Sealed()
@@ -350,7 +346,7 @@ abstract class State {
 
 In previous example `data` will not be automatically unwrapped.
 
-Also, when making a sealed sub class wrapped, its constructor and the corresponding factory in sealed super class will
+Also, when making a sealed sub-class wrapped, its constructor and the corresponding factory in sealed super class will
 be using positional arguments instead of named arguments. For example for `data`:
 
 ```dart
@@ -408,7 +404,7 @@ For more information check `super_enum` documentation:
 
 ### migrating from super_enum
 
-If you were using super_enum and now you want to change your dependency to dart_sealed:
+If you were using super_enum, and now you want to change your dependency to dart_sealed:
 
 * Change dependency of `super_enum` with `super_enum_sealed_annotations`.
 * Add dependency to `sealed_annotations`.