summaryrefslogtreecommitdiff
path: root/pages/develop/tutorials
diff options
context:
space:
mode:
authorXavi Artigas <xavierartigas@yahoo.es>2018-05-25 10:25:48 -0700
committerapache <apache@e5-web1.enlightenment.org>2018-05-25 10:25:48 -0700
commit8159c04ae77d07330401a1e4d2f30dcf9fc447cf (patch)
tree2fcafd19bddf96557f0b20d075edfb78f793bcb8 /pages/develop/tutorials
parent229a4bcb9f2dc4baac849a48cbcade29dfbc311e (diff)
Wiki page eo-multiinherit.md changed with summary [Updated to efl_new] by Xavi Artigas
Diffstat (limited to 'pages/develop/tutorials')
-rw-r--r--pages/develop/tutorials/c/eo-multiinherit.md.txt35
1 files changed, 25 insertions, 10 deletions
diff --git a/pages/develop/tutorials/c/eo-multiinherit.md.txt b/pages/develop/tutorials/c/eo-multiinherit.md.txt
index 8fcffd3c7..93508fc61 100644
--- a/pages/develop/tutorials/c/eo-multiinherit.md.txt
+++ b/pages/develop/tutorials/c/eo-multiinherit.md.txt
@@ -19,7 +19,7 @@ Allowing a class to have more than one parent has some caveats, such as the well
19 19
20C++, for example, allows you to create such hierarchies but forces you to specify which implementation you want to use in ambiguous cases. Most languages however solve the diamond problem by imposing restrictions on the classes from which you can inherit. These restrictions remove the possibility of ambiguous hierarchies and result in arguably cleaner code. 20C++, for example, allows you to create such hierarchies but forces you to specify which implementation you want to use in ambiguous cases. Most languages however solve the diamond problem by imposing restrictions on the classes from which you can inherit. These restrictions remove the possibility of ambiguous hierarchies and result in arguably cleaner code.
21 21
22Eolian (and [other languages](https://en.wikipedia.org/wiki/Mixin)) define two new kinds of classes, *interfaces* and *mixins* and imposes inheritance rules: 22Eolian (and [other languages](https://en.wikipedia.org/wiki/Mixin#Programming_languages_that_use_mixins)) defines two new kinds of classes, *interfaces* and *mixins* and imposes some inheritance rules:
23 23
241. You can only *inherit* from one *regular* class, which must be the first one in the inheritance list. 241. You can only *inherit* from one *regular* class, which must be the first one in the inheritance list.
25 25
@@ -29,7 +29,7 @@ Eolian (and [other languages](https://en.wikipedia.org/wiki/Mixin)) define two n
29 29
30*Inherit*, *implement* and *include* all mean *use functionality from a parent class*. Using a different word for each kind of parent class helps keep ambiguity to a minimum. 30*Inherit*, *implement* and *include* all mean *use functionality from a parent class*. Using a different word for each kind of parent class helps keep ambiguity to a minimum.
31 31
32Interfaces are like classes but they only define methods and contain no implementation. Mixins are classes which contain implementations but they cannot be inherited from, only included. Neither is instantiable on its own : they are meant to be implemented or included. 32Interfaces are like classes but they only define methods and contain no implementation. Mixins are classes which contain implementations but they cannot be inherited from, only included. Neither is instantiable on its own: they are meant to be implemented or included.
33 33
34The following steps will clarify these concepts. 34The following steps will clarify these concepts.
35 35
@@ -158,9 +158,9 @@ Pay careful attention to the ``-I`` switch so it can find the new class you are
158 158
159This means that in the implementation file you will now find: 159This means that in the implementation file you will now find:
160 160
161*An empty method where you must put the implementation for ``Example.Shape.area()``: ``_example_rectangle_example_shape_area()``. 161* An empty method where you must put the implementation for ``Example.Shape.area()``: ``_example_rectangle_example_shape_area()``.
162 162
163*Your previous implementation of the ``Example.Rectangle.area()`` method: ``_example_rectangle_area()``. 163* Your previous implementation of the ``Example.Rectangle.area()`` method: ``_example_rectangle_area()``.
164 164
165Simply move the one-line implementation (``return pd->width * pd->height;``) from the old method to the new one, then completely remove the old one. 165Simply move the one-line implementation (``return pd->width * pd->height;``) from the old method to the new one, then completely remove the old one.
166 166
@@ -258,7 +258,7 @@ _example_circle_radius_set(Eo *obj EINA_UNUSED, Example_Circle_Data *pd, int rad
258} 258}
259 259
260EOLIAN static int 260EOLIAN static int
261_example_circle_radius_get(Eo *obj EINA_UNUSED , Example_Circle_Data *pd) 261_example_circle_radius_get(const Eo *obj EINA_UNUSED , Example_Circle_Data *pd)
262{ 262{
263 return pd->radius; 263 return pd->radius;
264} 264}
@@ -284,7 +284,7 @@ _circle_create()
284{ 284{
285 Example_Circle *circle; 285 Example_Circle *circle;
286 286
287 circle = efl_add(EXAMPLE_CIRCLE_CLASS, NULL, 287 circle = efl_new(EXAMPLE_CIRCLE_CLASS,
288 efl_name_set(efl_added, "Circle"), 288 efl_name_set(efl_added, "Circle"),
289 example_circle_radius_set(efl_added, 5)); 289 example_circle_radius_set(efl_added, 5));
290 290
@@ -421,7 +421,7 @@ _example_colored_color_set(Eo *obj EINA_UNUSED, Example_Colored_Data *pd,
421} 421}
422 422
423EOLIAN static void 423EOLIAN static void
424_example_colored_color_get(Eo *obj EINA_UNUSED, Example_Colored_Data *pd, 424_example_colored_color_get(const Eo *obj EINA_UNUSED, Example_Colored_Data *pd,
425 int *red, int *green, int *blue) 425 int *red, int *green, int *blue)
426{ 426{
427 if (red) 427 if (red)
@@ -435,14 +435,29 @@ _example_colored_color_get(Eo *obj EINA_UNUSED, Example_Colored_Data *pd,
435#include "example_colored.eo.c" 435#include "example_colored.eo.c"
436``` 436```
437 437
438## Step Ten: Using the Mixin ## 438## Step Ten: Including the Mixin ##
439
440Modify ``example_rectangle.eo`` to include the ``Example.Colored`` Mixin. There's nothing to do beyond adding the Mixin name in the inheritance list:
441
442```
443class Example.Rectangle (Efl.Object, Example.Shape, Example.Colored) {
444 [...]
445}
446```
447The Mixin provides a new property to the class, and takes care of its implementation. ``Example.Rectangle`` (and its derived class ``Example.Square``) can start using this new property without further work. You can now generate the C files as usual:
448
449```bash
450eolian_gen -gchi example_circle.eo -I .
451```
452
453## Step 11: Using the Mixin ##
439 454
440Modify ``eo_multiinherit_main.c`` to make use of this new functionality. There's little to change. 455Modify ``eo_multiinherit_main.c`` to make use of this new functionality. There's little to change.
441 456
442Add a new configuration call to ``example_colored_color_set()`` in the creation of the rectangle: 457Add a new configuration call to ``example_colored_color_set()`` in the creation of the rectangle:
443 458
444```c 459```c
445 rectangle = efl_add(EXAMPLE_RECTANGLE_CLASS, NULL, 460 rectangle = efl_new(EXAMPLE_RECTANGLE_CLASS,
446 efl_name_set(efl_added, "Rectangle"), 461 efl_name_set(efl_added, "Rectangle"),
447 example_rectangle_width_set(efl_added, 5), 462 example_rectangle_width_set(efl_added, 5),
448 example_rectangle_height_set(efl_added, 10), 463 example_rectangle_height_set(efl_added, 10),
@@ -452,7 +467,7 @@ Add a new configuration call to ``example_colored_color_set()`` in the creation
452Do the same for for the creation of the square: 467Do the same for for the creation of the square:
453 468
454```c 469```c
455 square = efl_add(EXAMPLE_SQUARE_CLASS, NULL, 470 square = efl_new(EXAMPLE_SQUARE_CLASS,
456 efl_name_set(efl_added, "Square"), 471 efl_name_set(efl_added, "Square"),
457 example_rectangle_width_set(efl_added, 7), 472 example_rectangle_width_set(efl_added, 7),
458 example_colored_color_set(efl_added, 64, 64, 64)); 473 example_colored_color_set(efl_added, 64, 64, 64));