mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2026-02-14 06:25:00 +01:00
Code Issues Packages Projects Releases Wiki Activity

Updated trunk

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2484 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eifops
2025-02-06 17:17:32 +00:00
parent dfeab946bd
commit de6e7aad63
89 changed files with 516 additions and 129 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki
View File

@@ -1,4 +1,4 @@
[[Property:modification_date|Mon, 23 Jan 2023 09:14:48 GMT]]
[[Property:modification_date|Tue, 13 Aug 2024 09:46:34 GMT]]
[[Property:publication_date|Mon, 23 Jan 2023 09:14:48 GMT]]
[[Property:title|ET: The Dynamic Structure: Execution Model]]
[[Property:weight|-10]]
@@ -298,7 +298,7 @@ This would be awkward. Infix and prefix notations solve the problem, reconciling
end
</code>
Such a feature has all the properties and prerogatives of both normal "identifier-dot" notation and infix notation. This allowing invoking <code>plus</code> using either notation: <code>i.plus (j)</code> or <code>i + j</code> . A feature such as <code>plus</code> allowing infix notation must be a function, and take exactly one argument.
Such a feature has all the properties and prerogatives of both normal "identifier-dot" notation and infix notation. This allowes invoking <code>plus</code> using either notation: <code>i.plus (j)</code> or <code>i + j</code> . A feature such as <code>plus</code> allowing infix notation must be a function, and take exactly one argument.
Prefix notation is allowed as well. A function can be declared as <code>opposite alias "-" </code>, with no argument, permitting calls of the form <code>-3</code> rather than <code>(3).opposite</code> .
@@ -671,7 +671,7 @@ These attribute specializations are presented in the [[Void-safe programming in
Another special type of attribute supported by Eiffel Software's compiler is the '''transient attribute'''. When an instance of a class to which a transient attribute belongs is saved to persistent storage, the field for the transient attribute is not included. So, transient attributes are transient in the sense that they are part of the object at runtime, but not when the object is stored on disk.
This type of attribute has benefits when using the persistence mechanisms provided with EiffelStudio, like [http://eiffel.com/developers/learning_maps/Training/Maps/PersistenceCanPayOff/Serialization.html SED]. Because transient attributes are not stored, they need not be accounted for upon retrieval. So, objects stored before changes to a class that only affect transient attributes will still be retrievable using the new class definition (whereas, if non-transient attributes were changed, a mismatch would occur during retrieval).
This type of attribute has benefits when using the persistence mechanisms provided with EiffelStudio, like [[Persistence, storage, and retrieval#With_the_SED_persistence_format|SED]]. Because transient attributes are not stored, they need not be accounted for upon retrieval. So, objects stored before changes to a class that only affect transient attributes will still be retrievable using the new class definition (whereas, if non-transient attributes were changed, a mismatch would occur during retrieval).
An attribute is marked as transient by including a note option in its declaration: