[ Draft ]
Contents
- In & Out
- By Value
- By Reference
- Value In
- Value In in a Diagram
- Value Out
- Value Out in a Diagram
- Value Thru
- Value Thru in a Diagram
- Reference In
- Reference Out
- Reference Out in a Diagram
- Reference Thru
- Reference Thru in a Diagram
- Object Out
- Object Out in a Diagram
- Structs Parameter Passing
- Ambiguity of Input / Output for Reference Parameters
- Longer Names
- Three Parameter Passing Elements
- Parameters of Calls Directly Tied Together
- Strict About Parameter Passing
- The Class of a Parameter
- Type Arguments
- Sub-Commands Are Never Output Objects
- In, Out & Thru Parameters
- Downput
- Incidental Parameter Passing
- Indirect Value Transmission
- Wrong Approach to the Terms In, Out and Thru
- Brainstorm 2008-09-27
- Brainstorm 2008-09-26
- Loose Ideas
- From the Original Symbol Documentation from 2004
These articles may talk about input and output parameters.
Input seems what's read. Output seems what's written. But perhaps also in the context of the containment struct`ure: input seems read on the inside. Output seems written on the inside. But read on the outside! So the terms input and output do not seem to map neatly to reading and writing, but seem quite dependent on context in a containment structure: inside or outside.
Another thing slightly open to interpretation might be, that reading/writing parameters may involve the direct value or object reference of a parameter, not so much the things deeper in the containment structure.
A parameter is By Value, if you can only publicly read or write the value of the object.
Passing a parameter by value means, that the input or output is copied to or from the parameter object.
The diagram below may represent a By Value parameter tied to the value source or target:
The diamond is the command. The circle inside it is the parameter. The circle outside the command is the value source or target. And the wavy line may indicate value transmission between the parameter and the other object.
It may actually be a value assignment, that performs a yield over of value. Here is a diagram showing such a value assignment:
Parameters passed by value might be useful for smaller amounts of data. The data might be changed inside the command, but that might not affect the original object.
For an object, that only stores one value and that’s it, it may be ok to just copy the value.
Next to passing a parameter by value, you can also pass a parameter by reference. For instance: instead of copying a value to an input parameter, a command might be passed reference to an object outside the command.
If you want to pass more complex objects to a command, this might be done by reference instead of by value, but then changes to the parameter might affect the original objects.
Reference parameter:
A Value In parameter passes a value from an object to the parameter of a command. A Value In parameter is an object inside the command call, that can be written before the command is invoked, by assigning to it a value of an object outside the command call.
The command can manipulate the Value In parameter without affecting the original object.
A diagram of an executable command with a Value In parameter:
Here is a diagram of an unfilled-in Value In parameter of an executable command:
<< parameter passing >>
A command definition or other inactive command displays Value In parameters the exact same way. The Value In parameter of a command definition is usually not filled in:
But the Value In parameter of an inactive command could be filled in just as well:
<< interpretation >>
The fact, that it is an inactive command, means that it might not run, but for the rest it is the same as any other command object, so it basically has the same possibilities.
A Value Out parameter is a value produced by a command, that can be yielded over to another object after the command is done. A Value Out parameter is an object inside the command call, that is written to by the command or by one of its sub-commands. After execution of the command the value of the output parameter can be copied, by assigning the value to another object.
A diagram of an executable command with a Value Out parameter looks as follows:
The following diagram shows the Value Out parameter with an assignment target indicated to which the output value might be transferred:
<< parameter passing >>
A command definition or other inactive command displays Value Out parameters the exact same way. The Value Out parameter of a command definition might look like this:
The Value Out parameter of an inactive command can also be read and written to a target object, like this:
<< interpretation >>
The fact, that it is an inactive command, means that it might not run, but for the rest it is the same as any other command object, so it basically has the same possibilities, even reading and writing its parameters.
Throughput by value is when a by value parameter is first written to, then changed by the command, and then the value of the parameter is read from again, and assigned to the original object.
A Value Thru parameter is an object inside the command call, that can be written before the command is invoked, by assigning to it a value of an object outside the command call. It is used but also written to by the command or one of its sub-commands. After execution of the command the value of the throughput parameter can be copied, by assigning the its to another object.
<< details >>
In theory the value could first come from one object, and after the call be written to another object. But that’s not regularly what a Value Thru parameter is used for. The value might first be copied from one object and assigned to the parameter, and afterwards the value of the parameter is copied to the original object again.
A diagram of an executable command with a Value Thru parameter:
Here is a diagram of an unfilled-in Value Thru parameter of an executable command:
A command definition or other inactive command displays Value Thru parameters similarly. The Value Thru parameter of a command definition is usually not filled in:
But the Value Thru parameter of an inactive command could be filled in just as well:
<< interpretation >>
The fact, that it is an inactive command, means that it might not run, but for the rest it is the same as any other command object, so it basically has the same possibilities.
A Reference In parameter might be used to assign a reference to a complex object as the input of the command. Because a Reference In parameter is input, the called command can only read out of the object, that it was given a reference to.
A diagram of an executable command with a Reference In parameter may look as follows:
When a Reference In parameter might not have a reference target filled in yet, then the diagram may look as follows:
An inactive command displays Reference In parameters similarly.
<< interpretation >>
The fact, that it is an inactive command, means, that it might not run, but for the rest it behaves the same way as any other command object, so it basically has the same possibilities as an active command.
<< parameter passing >>
The reference target of a Reference In parameter of an inactive command definition might not be filled in.
Here is a picture in which a command definition’s Reference In parameter might have its reference target filled in:
<< interpretation >>
Do note, that the expression of read-write direction is not a connector, like for Value parameters. It is an abstract expression of value direction. You can not connect anything to it. The reference target connector, however, is a connector.
The distinction between Reference In and Reference Out might be about whether values are read or written to the object passed to the sub-command.
When a command is passed a reference to an object, and the command writes to the parameter, it might be called a Reference Out parameter. Because a Reference Out parameter is output, the called command might only write to the object, that it was given a reference to. A Reference Out parameter can be used to assign a reference to a complex object to which a command writes output.
A diagram of an executable command with a Reference In parameter may look as follows:
The access mark on the left is a connector, to which the reference target of the Reference Out parameter can be attached. Here an attempt to depict a diagram in which a reference target may be attached to the Reference Out parameter.
The fact that the reference goes outwards, might not make it an Out parameter. That just makes it a Reference parameter. The fact, that the command only writes to the parameter may make make it an Out parameter, so the term Out is about value direction, not reference direction.
An inactive command may display Reference Out parameters in a similar way.
<< interpretation >>
The fact, that it is an inactive command, means, that it might not run, but for the rest it behaves the same way as any other command object, so it basically has the same possibilities as an active command.
<< parameter passing >>
The reference target of a Reference Out parameter of an inactive command definition might usually not be filled in:
Here is a picture in which a command definition’s Reference Out parameter might have its reference target filled in:
<< interpretation >>
Note, that the indication of read-write direction is an abstract expression of the value direction inside the command. You can not connect anything to it.
Next to Reference In and Reference Out, there might also be Reference Thru, which may means, that the command both reads and writes to the object passed to it. A Reference Thru parameter might be a pointer to something outside the command. The object pointed to may be both read from and written to.
<< interpretation >>
A Reference Thru parameter can be used to assign a reference to a complex object, from which input is read and output is written to.
A diagram of an executable command with a Reference Thru parameter may look as follows:
When a Reference Thru parameter might not have a reference target filled in yet, then the diagram might look as follows:
An inactive command may display Reference Thru parameters similarly.
<< interpretation >>
The fact, that it is an inactive command, means, that it might not run, but for the rest it behaves the same way as any other command object, so it basically has the same possibilities as an active command.
<< parameter passing >>
The reference target of a Reference Thru parameter of an inactive command definition might not be filled in:
Here is a picture in which a command definition’s Reference Thru parameter might have its reference target filled in:
<< interpretation >>
Do note, that the expression of read-write direction is not a connector. It is an abstract expression of value direction. You can not connect anything to it. The reference target connector, however, is a connector.
<< parameter passing >>
An Object Out parameter might be an object, that resides inside the command. The Object Out parameter may be a new object, or redirect to an existing object. Anyway, the command might determine which object may be output. The produced object can be referenced from outside the command.
<< rule rich >>
Unlike parameters passed By Reference, an Object Out parameter is referred to. This is an exclusive aspect of the Object Out parameter passing.
<< parameter passing >>
So this is a Reference Inward parameter, as opposed to a Reference Outward parameter. The reference direction goes the other way around.
<< already covered >>
Instead of a parent passing an object to the command, it is like the command passes a reference back to container of the command.
<< parameter passing >>
The command writes to the output object.
<< rule rich >>
Unlike Reference and Value parameters, there is no distinction between In, Out and Thru for Reference Inward parameters. The reason Reference Inward parameters do not have three variations, is that the command’s reading and writing values to the object is irrelevant to the parameter passing. To the outside, it might not matter whether the parameter is read from or written to or both. All that matters, is that an object is produced. Reference Inward, Value In and Reference Inward, Value Thru are not relevant. The Reference Inward parameter can be read from by the sub-command, but that it’s just not relevant to parameter passing between a command and its container. Because Reference Inward, Value Out is only relevant for reading values from an output object, it is shortened to Object Out.
An Object Out should really only be accessed after the command has run.
An Object Out parameter can be a regular object, but it can also be a command. In that case it might be a command produced by another command. The parent command can return a new command or the parent command can return a reference to an existing command.
When an Object Out parameter is actually a new command, then the new command is either a pre-configured instance of another command, or it can be a brand new, generated command, any part of which is constructed by its parent command, based on a set of variables.
An Object Out parameter might be typed a New Object Out parameter, if it might be a brand new object that might be returned.
An Object Out parameter can also be an existing command. In that case the Object Out parameter object-redirects to another command again, so the parent command basically picked out a command for you, instead of actually producing a new one.
<< different section ? >>
In Circular, multiple return values is accomplished by having multiple Object Out parameters. So you do not need Reference Out parameters for that purpose anymore.
An Object Out can be typed more specifically as Existing Object Out if it might not be a new object that is returned, but one that already existed.
A diagram of an executable command with an Object Out parameter may look as follows:
The outer end of the line is an connection point to which you can connect an object to refer to the Object Out parameter:
An inactive command might display Object Out parameters in a similar way.
<< interpretation >>
The fact, that it is an inactive command, means, that it might not run, but for the rest it behaves the same way as any other command object, so it basically has the same possibilities as an active command.
<< parameter passing >>
The object referring to the Object Out parameter of an inactive command definition might not be filled in:
Here is a picture in which a command definition’s Object Out parameter might have a referrer:
A construct that other languages might call structs, are a value type that might have multiple distict fields / values.
This type of construct's value might be transferred with a cloning depth of 2. The idea that the object itself + its values are transferred as a whole in case of value assignment, and by extension also By Value parameter passing of a struct.
It may happen automatically for struct types. A clone notation where the cloning depth of 2 might be visually expressed, might also be suggested. This clone notation may be found in a separate document.
No definite choice might be necessary about which notation to pick. It might depend on the particular application that may be developed that perhaps would use this Circular notation.
<< move ? >>
<< ambiguity of input / output for reference parameters >>
When a command call has an outward reference to an object, this might make the object a parameter. It seems an input parameter, since the line might be set from the outside. But it seems ambiguous whether it is input, because values might still be read or written. It being an outward reference, might not determine yet whether it is input, output or throughput. The in and out in this case refer to whether values are written or read to the object reference. A reference parameter is always sort of like input, though: the parent command passes the object to the sub-command, so the parent inputs something into the sub command.
<< ambiguity of input / output for reference parameters >>
In a sense, a Reference Out parameter is actually throughput.
When output is alteration of an existing object, it could be considered throughput, even though there is only written to the object, and nothing is read from the object, it is still an object passed through the command. In yet another sense, a Reference Out parameter is input, because you are passing an object into a command.
<< ambiguity of input / output for reference parameters >>
The reason why it is important to keep understanding the three aspects of parameter passing, is that Reference parameters, even though they can be In, Out or Thru, are always input in a way, because it is a reference passed from the parent command to the sub-command.
A By Reference parameter can also be called Reference Outward, Value In and Reference Outward, Value Out But those names may be quite long.
The long names of parameters passed By Reference were:
- Reference Outward, Value Inward
- Reference Outward, Value Outward
- Reference Outward, Value Thru
The long name of value Object Out might be:
- Reference Inward, Value Out
Long names for the different parameter passing types might be:
- Value In
- Value Out
- Value Thru
- Reference Outward, Value In
- Reference Outward, Value Out
- Reference Outward, Value Thru
- Reference Inward, Value Out
Reference Inward, Value InReference Inward, Value Thru
But these two might not be relevant:
- Reference Inward, Value In
- Reference Inward, Value Thru
<< interpretation >>
By Value, Reference Outward and Reference Inward might be the different reference situations a parameter can have. But this may not tell us whether a parameter is input, output or throughput. What might determine, whether it is in, out or thru may be whether values are written to the parameter or read from the parameter.
<< rule rich >>
Perhaps because a reference inward only is about an output object.
It might be relevant to observe that there might be three elements to parameter passing:
- Values read or written
- Parameter is a reference outward
- Parameter is referenced from the outside
To understand how the different parameter passings came about, it is important to keep those three aspects in mind.
<< parameter passing >>
Here is a list of the parameter passings, with their short names, and their diagram expression:
-
Value In
-
Value Out
-
Value Thru
-
Reference In
-
Reference Out
-
Reference Thru
-
Object Out
<< interpretation >>
Value In and Value Out means reading and writing done by de caller. Reference In and Reference Out means reading and writing done by the called command. In both cases In might mean, that the called command uses something, and Out means, that the called command returns something.
In other programming languages, sub-commands might not directly read or write to each other’s parameters. Parameters might only be read or written by the parent command.
However, in Circular, parameters of commands might be tied together directly.
One type of parameter passing might only be tied to a parameter with a specific other parameter passing.
Value In parameters and Value Out parameters may be tied together:
Only Object Out and Reference parameters might be tied together:
Tying parameters may express a dependency. No direct reference to the parameter objects may be required inside the parent command in this notation.
<< rule rich >>
A Value Thru parameter can not be tied to another parameter:
This is because it creates a circularity in which one parameter writes its values to the other, and the other parameter writes its value to the first parameter. It is just an unlogical circular situation.
<< implementation >>
I really want the programming environment, to not so easily accept, that a parameter is typed throughput, when it is only read from. Because otherwise you rely too much on courtesy of the programmer, to make the whole system function correctly.
You could define a parameter as throughput, but actually only read from it. In that case the parameter is implicitly degraded to an input parameter. The implicit parameter type counts. The implicit parameter passing is dependant on the way it is declared and the way it is used. A throughput parameter is not only declared as such, but also always used as such.
The class of a parameter is usually set by the command, that holds the parameter. In that case, you can only assign objects or values of objects to it, that have the same class as the parameter indicates.
It is also possible, that a parameter might not have a class. In that case any object or any object’s value can be passed to the command.
When the class of a parameter might be determined from the outside, then it is special. It may be a Class Reference parameter. In that case you might not use it as a normal Reference parameter. In some other programming languages thes might be called type arguments.
<< rule rich >>
Sub-commands, so active command objects inside another command, are never referenced so sub-commands can never output objects.
The rule is explained in the article Sub-Commands are Never Referenced, as part of the set of rules that protect a parent command’s control over the execution of its sub-commands.
This rule also implies, that sub-commands (active commands inside another command) can not be output objects. If the rules that protect the parent’s control over its sub-command’s execution change, then the rule sub-commands are never output objects might not apply anymore.
A parameter, that is a command reference, can be run, but it can never point to an active command inside another command, so that never lets any parent command loose control over any sub-command’s execution.
Parameters can function as input, output and throughput. Input, output and throughput may be parameter passing types. They might be shortened to In, Out and Thru.
<< interpretation >>
When a command’s parameter is In, it means that the command reads from the parameter. When a command’s parameter is Out, it means that the command writes to the parameter. When a command’s parameter is Thru, it means, that the command reads and writes the parameter. Throughput functions as both input and output at the same time.
<< creation behavior of commands >>
Before execution you can read and write. > 2008-09-24 from the outside
During execution you can not read or write. > 2008-09-24 from the outside
After execution you can only read. > 2008-09-24 from the outside
<< terminology >>
Next to the terms input, output and throughput, the term downput might be introduced. Downput is intermediate data as a helper of a process, that might eventually produce output. Temporary variables, local variables. They are all downput. Actually, in the command-call structure, a command in which output data is disposed, this output has become downput.
Downput data is private data of the command.
The term downput might be a good term, because it is only passed down into sub-commands. And may be dropped after the parent command is done (dropped down). It is ‘put down’ / rejected after the execution. Or put down / to put something down, that you had in your hand.
When a command disposes objects after it is done, then those objects might be called downput. Downput may have been input for sub-commands, or it could have been output of sub-commands. To the parent command, though, it might be downput. Downput parameters might not be further considered here, because they might not have anything to do with parameter passing.
<< rule rich >>
One time a command runs, something may only be read. Another time it may be read and written to. This changes the implicit position of the object in relation to to the command for each call to the command. You could stereotype it an input parameter as Not Input and an output as Not Output and a thru parameter as Only Input or Only Output or Not Thruput. But it might not replace the parameter’s In, Out or Thru properties, because they belong to the command definition.
The object command’s on the other end of the relationship, also get additional typing based on the incidental parameter passing, but the passing names are not even determined yet.
< 2021-05-03: This may be like 'connector' vs 'connection'. >
<< input output >>
Used in abstract notations, explained later, a value line might not necessarily mean yielding over the value of one object on one end of the line to the other object on the other end of the line. It may be yielding over values between sub-objects. So it’s not synonym to a value assignment in that case.
But usually value direction means assigning the value of one object to another.
- > Indirect value direction may be called data direction, and might be given a double wavy line as a symbol. It can indicate addition, removal, creation, annulment and value transfers of the direct object or its sub objects.
For Reference parameters it might not need to be the value of the object itself, that is read or written.
It can also be a sub-object of the parameter, that is read or written. Even though the parameter itself is not read or written, but only its sub-object, the parameter itself is considered input or output, even though only the values of its *sub-*objects are used.
Sometimes the command itself might not read or write from a parameter, but the parameter is passed down to a sub-command, that reads or writes from the object. This yields over the in-out-thru properties of the parameter. This might give the parameter an indication of value direction, but this is an abstract notation of what is going on. The assignments are done by a sub-command.
Next to values being read or written, an abstract indication of value direction is also used to indicate addition, removal, creation and annulment of objects. These actions might all be considered writing or output.
In the definition of the command, you might see the individual additions, removals, creations and annulments as calls to system commands (see the System Interfaces documentation section).
But the Reference parameter might get an abstract value direction indication, that says the reference parameter is output.
All in all, non-value transmissions may apply to By Reference parameters only.
So for reference parameters, the in-out-thru direction might be an abstract indication of what is going on. It can mean a lot of different things.
The exact objects and manipulations a command might executes on a reference parameter might be indicated by its command IO, might be covered in a topic Command IO.
2008-09-29
<< terminology >>
<< in / out vs. read / write confusion >>
The terms I might like to see back in access control literals are the terms In, Out and Thru.
After a lot of brainstorm I figured, that whether something is In or Out depends on whether something is being written from the outside or on the inside. When something is set on both the outside and the inside, then it is called Thru. From which direction something is read is not relevant for the terms In, Out and Thru.
When you write one aspect on the outside, it might not mean that the same aspect is supposed to be read on the inside. You may write one aspect on the outside and read another aspect on the inside. For instance, if you write the object from the outside, you may only read its value from the inside. Earlier, this might produce the following literal:
- Object Set Public, Value Set Private
But the terms Set Public and Set Private can be replaced now by the terms In and Out:
- Object In Value Out
It looks a lot clearer that way.
If the same system aspect is written from both the inside as well the outside, then the term Thru might be used, for instance:
- Object In Value Thru
The keyword Thru can only be used, when it is the same aspect, that is set from both the inside and the outside. When different aspects are written on the inside and the outside, you might not see the word Thru in the access control literal. For instance, when a parameter is:
- Object In Value Out
it can be called a Thru parameter, but you might not use the term Thru in the access control literal, because you can only use the term Thru in a literal when the same aspect is set on both the inside and the outside.
The use of the keyword Thru may also become scarce, if you insist to keep the access control elements in chronological order:
- Object In, Value In, Value Get Private, Value Out
Even though Value is Thru, the Value Get Private is put in between the Value In and Value Out, because of the chronological order of access control elements. It is not clear yet what I want to do with this in the future. Perhaps a rule, that makes the literal:
- Object In, Value Thru, Value Get Private
But I am not sure yet.
<< terminology >>
<< in / out vs. read / write confusion >>
Reading stuff might not seem to have anything to do with the terms In, Out and Thru. In, Out and Thru only determine the write-direction.
Reading stuff seems to matter less. Reading might not be seen as parameter passing. It might be only about: who writes it and from which direction. Reading has less impact than writing.
<< input output >>
But its impact may become important later, when perhaps using it in more advanced techniques for for instance concurrency resolution.
<< terminology >>
<< in / out vs. read / write confusion >>
What I see now, is that if I find simpler terms for reading, I might probably be totally happy with my parameter access control literals. Since there is such beautiful names for writing from either inside or outside (In, Out and Thru) can I come up with beautiful names for reading too? If I can find a replacement for the terms Get Private and Get Public, then I might probably be completely satisfied with how the parameter access control literals look.
Next to an easier expression of Get Private and Get Public, you may also want to invent keywords to express that something is publicly written and privately read, or the other way around. So when Value is set on the outside and read on the inside, you get an easier expression for it, than saying Value In, Value Get Private. Do note, that when you set a value on the outside, it might not imply, that you also read the value on the inside.
< 2021-05-03: It may seem to matter less, the precise words. It might be more about the diagram notation and how it might map to perhaps more familiar concepts from programming. Even automatically determining in, out and thru might not be dependent on what names things are given. >
<< parameter passing >>
2008-09-29
However, New In might mean creation from the outside and New Out might mean creation on the inside... so ... it’s not just the inside then... how might that relate to the rest of the ideas about In, Out and Thru?
JJ
<< parameter passing >>
If an aspect is both In and Out and the two access control elements are right next to each other, it can be replaced by a single access control element Thru:
- Object Thru
- New Thru
- Annul Thru
- Value Thru
- Class Thru
<< input output >>
I think the terms input and output should not be about whether something is written from the outside and whether something is written from the inside. That’s what I did earlier. I think the term input should mean: everything that is read on the inside of a command, and the term output should mean: everything that is written on the inside of a command.
So it is about what happens on the inside. Whether something is written or read from the outside might not be the issue.
Anyway, input and output are too complicated to just wrap up the old parameter passing type stories, which depend on those terms.
Advanced Command Topics might also do a lot with input and output. Actually, most of it is about the complexity of input and output. I should really save it for another project. One of the objectives of the project Work Out Advanced Command Topics should be to determine the exact definition of input and output and the exact definition of input and output parameters.
I should shove it over to that project.
I should register in the project description that determining the exact definition of input and output is one of the objectives.
The current project might wrap up everything else about parameters.
I might clean up the objectives of the current project and create a new plan for it.
Then I can work my way up to an end point. And in the next project I might just calmly look at the exact complexity of input and output.
<< input output >>
<
2021-05-04:
- The following brainstorm may be about labeling things In and Out. A quest for simpler names might be observed.
- Perhaps a more relevant issue might be the elements: different ways that objects might be accessed like Public Get Value or Private Set Object. Perhaps not so much what to name it, but rather what elements there are and what the notation might be.
- Also edge cases might be given more attention than might be necessary.
- Another thing that emerges in the brainstorm might be: wanting a grip on what input and output precisely mean and how to define it precisely. That might be more for the Input / Output chapter in Construct Drafts.
My mistake may once have been to think: "These terms In and Out must be simple to define." and then might have gotten stuck on that for a while.
>
The problem with defining what is input and what is output, is:
- Is input what is written from the outside, or is input what is read from the inside.
- Is output what is read from the outside, or what is written on the inside?
You might think: both; something that is written from the outside is read on the inside and something that is written on the inside, is read from the outside.
But one prime example might overthrow that: An object can be written, so passed to a command, and the value of the object might be read. So Object Set Public, Value Get Private. So then you do not set the object, to read it on the inside, but the object is set, to read the value on the inside, so when an aspect, such as Object or Value, is In, it might not mean that it is both written from the outside and read on the inside.
But in the car on my way home from work I realized, that I have been forgetting about half the gets. When an object is written from the outside of the command, of which the Value is read on the inside, the Object is read as well, because might read the object, before you can retrieve the value of the object. So the object is read for access. Not for copy / assignment.
Perhaps you need to consider reading an object for access too. I already wrote something about that in the old Symbol documentation: different forms of getting, that also might be separately access controlled.
It makes a difference when something gettable for access compared to gettable for copying. It might make a difference for outcome dependency. For instance: when you can get something for accessing but can’t get something for copying, then the object can be accessed inside the command, but it can not be passed further down into sub-commands.
This has implications for automatic determination of in out and thru and also for compared IO and automatic execution order.
Perhaps I need to consider Command IO a little to come up with a more exact definition of input and output. But I think I am getting there now.
Outside the command, something is only written to the command, to be read from the inside of the command, even when it is not reading for assignment, but reading for access.
So the thing is: you don’t always read something only to write it to something else. You also can read something for access: read something for redirection to something else.
So that suggestion I made earlier was wrong.
So it seems, that after all input is: written from the outside, read on the inside. And input is: written on the inside, read from the outside. reading can also mean reading for access, not reading for assignment.
But there is one thing wrong here:
- incidentally something that is written from the outside, is not read on the inside
- and incidentally something that is written on the inside, is not read from the outside.
- Incidentally something is not written from the outside at all, but read on the inside all that same, but then a default value is read or an error or something missing is caught.
- Incidentally something was not written on the inside, but read from the outside all the same, but then a default value is read of an error or missing of something is caught
That has to get a name: so it is a missing read or write of input or a missing read or write of output.
But still:
- input means writing on the outside, reading on the inside.
- Reading can also be reading for access. Not necessarily reading for assignment
- Reading for access and reading for assignment need to be separately access controlled and it might change parameter passing.
- Incidentally a read or write of input or output is missing. That might be given a term.
- When a read or write is done on the outside, the a write or read might be executed on the inside, even though scarcely or incidentally not.
If you don’t read input, then you can not call it input: an error or warning is generated.
- In For Access
- In For Copy
- Value In For Redirection > not possible
- Value In For Copy
- > is just Value In
- Object In For Redirection
- Object In For Copy
- Class In For Access
- > How can you access a class? Don’t you only access an object? Yeah, I think you do. So the separation between 'for access' and 'for copy' may only count for Object access.
So:
Object Set Public, Value Get Private
=
Object Set Public, Object Get Private For Redirection, Value Get Private
Hmmm... if you get the value of an object, might that mean you first follow redirection? I guess you do..
The last bit of the access control literal specifies, you can only follow redirection of the object to get the value or otherwise it might be Data Get Private.
But the access literal above further simplified
= Object In For Redirection, Value Get Private.
Now I am confused again: you may set and get the object, but you only GET the value. Weren't I supposed to call something input, when it is set from the outside and read from the inside.
The thing is: I am not reading what’s set on the outside: I am reading from what’s inside what’s set on the outside.
So you are going further down the structure when you read the value of the object passed to the command.
So Value In means you write the value from the outside, not the object, and you read the value on the inside. Value Out means the other way around.
Actually, it could be: Value Set Public, Object Get Private For Copy.
Value is Set, but not read. Well.. it has to be read by a sub-command then...
I am still confused. I have brainstorming to do.
But it’s no use writing something, if you don’t read it at some point.
Sub-commands yield over in, out properties to their parent commands.
You write the value... it needs to be written at some point.
When you write the value from the outside, and you can only access the object on the inside, you might pass the object to a sub-command, that might write the value. But can you really know? Maybe not, but it should be read somewhere on the inside.
Look, there is a whole object theory behind the in out and thru. And it should be covered by advanced command topics, to the extent, that you can automatically determine execution outcome dependency, execution order and possible resolve concurrency.
But writing means you’re going to read it, and when you read it, is has to have been read.
Oh, yeah? What if you write the value of the object some place, and the object is passed to the command, and the command reads its value. In that case the value is only written to the object somewhere on the outside, and read only somewhere on the inside.
Is there really a point to talking about input and output at this stage?
Isn’t input and output much more complicated than expected.
The general meaning is understandable, but what it means on an object oriented level could be very complex. I really think it is something for Advanced Command topics.
I can talk about Reference In, but when you assign the object to a parameter, and the value is supposed to be accessible, it doesn’t mean, that you might read the value directly in the command. You may very well read it somewhere in a deep sub-command.
This whole theory about how something becomes input or output might just be saved for Advanced command topics. And things like Reference In and all that, are just not as simple as suggested.
Perhaps a simpler conclusion, for now:
the rules I suggested above are still true: when you set input, it is meant to be read somewhere, but WHERE you actually read it is more complicated.
But when you SET something of a parameter, than you are sure it is input or output.
Where you then GET it, is not clear. It could be far away on a higher level, or far a way on a deeper level. That’s why SETTING allows you to say something about something’s being input or output. But can the ability to set a parameter on either inside or outside exclusively tell you it is input or output?
What use might access control over getting have?
I think being able to allow a Set from the outside, and then still being able to disallow getting on the inside might be unuseful: it has to be gotten at some point, if only for redirection.
So those allowances should go hand in hand: if you can write it from the outside, you can read if from the inside. If you can write it on the inside, you can read it from the outside.
but WHERE it is then read could be somewhere totally else than directly outside or directly inside. MIGHT THAT count for SETTING too?
<< parameter passing >>
Parameters,
2008-08
The command definition can also contain a set of related objects. Those are the parameters of the command. They are just input, output, throughput or downput. This input, output, throughput and downput is passed on to the sub-commands, that are given outward references to these items.
JJ
Parameter passing,
2008-09-05
<< terminology >>
If a command parameter is typed with in, out, or though,
then an object command can also be given a title depending
on whether it might be input, output, throughput, etcetera.
input is not an object that something is done to. It can be considered an object doing something to another object. So it is clearly an actor.
<< thruput parameters | affected used and transformed >>
It matters whether the object is used (read), affected (written), or produced. This alters the object’s position in relation to to the command.
JJ
Parameters,
2008-06
<< input output >>
Always something is the input and something is the output: at least one thing is used, and at least one thing is affected. But the affected thing can also be a new thing.
One thing is executed on another. So its data executed on data.
JJ
Access Controling System Aspects,
2008-09-21
<< broader view >>
When you access control the system aspects of a parameter, might this have implications for access control of the object’s command?
When you show a command inside an object, how might you see, that the command outputs the object or if the command uses the object?
JJ
<< get purposes >>
2008-09-26
Adapt the access control of system aspects in the parameter articles to Object Get for access and for copy...
JJ
Parameters,
2008-09-11
<< construct drafts >>
Value In parameter used for selection
Value In parameter used for persistance
JJ
<< details >>
When a command is called, objects are filled into the parameters of the command. A command might use objects to do its work. The objects filled in as parameters are also called arguments.
As commands call each other, every time different data is passed along to the different commands, that are called.
<< details >>
ByRefs have pros and cons in different situations.
<< parameter passing >>
The objects inside a command can be regarded:
- Input parameters
- Output parameters
- Throughput parameters
- Return values
- Local variables
<< parameter passing >>
The input parameters of a command are its writable objects. The output values are its readable objects. Objects that are read-write are like in-out or thru parameters.
<< return values >>
One readable object can be chosen to be the return value, which promotes it to being the main output parameter. This might not give it extra capabilities, only an extra notation in certain places. The return value might be denoted in a diagram by putting the term Return near one of the parameters.
< Don’t forget that you don’t need to read or write necessarily, you can also just call a member of the parameter instead of read or write it... explore that >
<< command in >>
Passing a command reference,
When you pass a command reference to a child command:
The child can call the referenced command at will.
<< already covered >>
<< perhaps usable >>
Commands can have parameters: instructions passed along with the command that make the command behave differently. The Button . Set Text command, for instance, has a Text parameter, which indicates what the new text of the button might be.
Text is an idea. It is an object. It is objects that serve as parameters.
The command can do whatever it wants with the parameters passed to it. All it really can do with it is again pass the parameter to another command or call commands of the parameter.
Pass the Text parameter on to the next command (Format Text):
Call the a command of the Text parameter:
The terms parameter and argument are often intermixed. For now you can assume that a parameter is a setting of a command and an argument is the value that it holds. That’s not the entire truth, though, but I’ll save the exact meaning for later.
<< nice formulation >>
Parameters are commonly input (instructions) for a command. Parameters can also be output (returned results). They make a command return something to the caller. One of the output parameters can be appointed to be the return value, which makes it sort of like the main output parameter. Some parameters can be input, and then output again. Then the command uses the parameter, transforms it and gives it back in the transformed state. These parameters are called throughput parameters, or in-out parameters. There are also objects in a command that are only used locally. Those are not usually called parameters, but sooner called local objects.
<< in / out vs. read / write confusion >>
< 2008-10-06 Move to Input Output >
The command output method above is hardly used ever used. That’s because you can’t really tell if the target object might keep existing, unless you’ve defined the object yourself. Therefore, using output other than state output is usually done by passing a reference to an existing object to the command.
This, however requires you to write the line of an argument.
Nothing is read in the epilog in this case. Even though the argument functions as output, it’s still a write argument.
Any line going out of a diamond is set just before the diamond executes.
<< in / out vs. read / write confusion >>
As such, read and write arguments is not analogous to input and output arguments. A write argument can easily serve as an output argument.
< 2021-05-02: It might be about context: reading from the inside, writing on the outside versus writing on the outside, reading on the inside. It seems about reading/writing in the context of containment structure. >
<< details >>
Reference arguments can serve as input, output and throughput. State arguments can serve as input, output and throughput too.
<< rule rich >>
You’ll hardly use a line target as output information. You’ll probably use an argument’s line target only to pass an object by reference.
Even though an argument’s line is hardly ever read, an argument’s state is commonly read.
<< parameter passing >>
You’ll mainly use arguments by reading and writing their state or to pass objects by reference.
<< creation behavior of commands >>
Apart from writing in the prolog and reading in the epilog, there’s a third period in which you can access an argument: during execution. You can only access the arguments of a diamond in execution. The caller of the diamond is frozen, till the execution completes, so the caller doesn’t have any chance of accessing the arguments during execution. However, everything inside the executor is in motion. The executor itself can freely access its arguments, of course, but also anything it calls, could access its arguments, if given a reference. But, as I said, the caller of an execution can’t access the arguments during execution.
<< details >>
The diagrammatic effect of this is the following. A member can be accessed by the diamond that contains it, and by all its sub diamonds:
I said, that commands called by a command can access its arguments. That suggests that the command that accesses the member can be somewhere else than inside the member’s diamond:
Note, however, that it’s not the definition that’s accessing member m. It’s the call that’s accessing member m, and the call is contained inside the diamond that contains member m.
More rules on that are covered in the Execution Basics section.
<< parameters of calls directly tied together >>
<< implicit calls >>
< you can call an implicit call a parameter reference too. Mention it so you show that there’s a big difference between parameter reference and argument reference >
- Implicit call and Explicit call
- Implicit return value reference
- Implicit argument assignment
####### Referencing Square Members: Implicit Call
<< rule rich >>
It is really only allowed to reference members of diamonds:
When you do reference a square’s member:
You’re actually seeing only part of the diagram. The reference to a square member actually creates a sibling diamond which is a call to the square:
The diamond missing when referencing the square member is called the implicit call to the square.
Even though the Symbol code really defines a reference to a square member, when the code is executed, it’s treated as having an extra diamond. Allowing referencing a square member can simplify the notation in many cases, that’s why it’s allowed.
The implied diamond always becomes the sibling of the reference to a member. In a more encapsulative situation, this:
Is the implicit notation of this:
The reference to a square member implicitly creates a call to the square right next to it.
Whenever you reference a square member, an implicit call is made.
=
< Add some access symbols >
If you want to access members of a command using only one call, you might explicitly notate the diamond that is the call.
< Add some access symbols >
But the accesses can only only take place just before the call and just after.
But as I said: child diamonds can access their parent diamond’s members if the parent diamonds allows it.
####### An Object symbol as a Pointer to a Command Symbol: Implicit Return Value Reference.
<< return values >>
You can also let an object symbol point to a command symbol.
In that case you’re actually implicitly referencing the return value.
####### Implicit Call and Implicit Return Value Reference
<< implicit calls >>
<< rule rich >>
If an object symbol is a reference to a square, it’s both an implicit call and an implicit return value reference.
in the second picture you see the explicit call. The third picture adds the explicit return value reference. You don’t first do the explicit call and then the explicit return value reference. That order is totally arbitrary, you can also see it like this:
####### Reference to Other Out Parameters
<< return values >>
An object reference to a command can only be a reference to the command’s return value. If you want to reference other out parameters, you might reference them explicitly.
(o = out, r = return)
a can only be a reference to r, the return value. b is a reference to o, another out parameter.
<< interpretation >>
There are three ways to use arguments: state read, state write and passing by reference:
 |
 |
 |
|---|---|---|
| State read | State write | Pass by reference |
There seems to be one more: argument reference.
Argument reference:
<< interpretation >>
<< rule rich >>
<
If it is interpreted as an implicit assignment call, things seem to fall in to place. And then the following ideas might not be needed.
>
This is however not possible, because the argument destroys after execution, so you can’t reference it after execution, because then there is nothing left to reference anymore. Argument reference is useless.
Argument reference is actually a fictive concept.
It is actually an implicit notation for a reference argument:
There’s more to getting the explicit notation of argument reference than just inversion of direction. Consider this diagram:
This diagram has two argument references in it. If you might simply invert the direction you’d get the following:
(Note that the last access symbol didn’t change, because that line isn’t an argument reference)
It still has a argument reference in it.
The explicit notation that solves this is the following:
The child diamond is inserted as a substitute for the higher diamond it refers to. This offers a solution because the parent of the child diamond might exist when the child exists. {This might be an issue for multiple execution of a diamond. It also raises the question what happens when you consult something of the diamond on the right. Is the bigger diamond executed first? What?} That’s rule two for getting to the explicit notation of parameter reference.
< I have doubts about this third rule. I think this case might be illegal. I need to find the rule on what makes it illegal and how you see the illegality of it in the implicit notation >
There’s one more problem. The explicit notation introduced so fat has a flaw: the object has two line targets! If a situation as such occurs, the directions of all flawed non-argument references are inverted:
Which gives is rule three of the explicit notation of argument reference.
If a reference argument targets the argument of a parent diamond, it is not considered an argument reference.
Argument reference is only the case where you enter a diamond.
So the implicit argument reference notation:
Has the following explicit notation: < I know it is wrong, I should investigate later >
Rule 1:
A argument reference (a line entering a diamond) is an implicit notation of the reverse direction (a reference parameter).
Rule 2:
If the line both enters and exists a diamond, then the inversion of direction doesn’t solve it. < > In that case, a child diamond is created in the diamond that holds the argument reference. The diamond references the diamond that held the argument reference target. The new child diamond is used instead. < >
Rule 3:
< ... >
You go from implicit to explicit notation in the following steps:
Reverse direction of argument references
Create child diamonds where the inversion doesn’t work
Invert the direction of other lines that became faulty
<< interpretation >>
<< rule rich >>
< The out parameter access symbol isn’t required, so the notation of it suggests that it’s an in parameter reference. >
Argument reference notation (an implicit one):
is saying that the actual reference argument:
Is used as out and not as in.
The explicit notation:
can be in, thru or out. But the access symbol is usually not notated in case of outward direction:
Therefore this outward notation with an access symbol suggests that it’s an in argument.
Thru can be notated as:
Which is not a real bidirection, because the line can’t really go inward anyway. It’s an implicit notation.
As such, there are six explicit argument purposes:
 |
 |
 |
|---|---|---|
| State in | State out | State thru |
 |
 |
 |
| Reference in | Reference out | Reference thru |
<< text code >>
The resulting sequence of code lines corresponds to the execution order required for dependency. As you change the diagram, the order of the text code can change. You can freely move around text lines of sibling symbols.
< The resulting sequence of code lines and the execution order within code lines. >
< Don’t cover exact text code here >
####### Implicit Calls
<< implicit calls >>
< 2008-10-08 The texts that follow use an old notation for calls: a definition is a square without a reference line, a call is a square with a reference line. >
< Maybe diagrams can be more basic, expressing solely a concept >
< Reference a command parameter from an object. >
To explain this concept I use an example where one command, called Get, returns an object that is then passed to another command, called Set. This requires two calls: first a call to Get and then to Set.
######## Explicit Calls
<< implicit calls >>
The steps of this process can be described as follows:
Get
Set . In = Get . Out
Set
The out parameter of Get is called Out and the in parameter of Set is called In. In diagram code, that is:
Explicit calls:
Only the blue parts are shown in the piece of text code. You can see that Get is called and Set is called. Both Get and Set have a parameter. The parameters are shown in the definition, but also in the call. In the call, the parameters are actually created and the parameters in the calls are worked with. The Out of Get and the In of Set are tied together with an object line. You can’t explicitly see the order in which Get and Set are called, but because the Set call references a parameter in the Get call, Set is dependent of Get, therefore Get is called first.
######## Implicit Calls
<< implicit calls >>
In text code you can write the two calls in a single code line:
Set ( In = Get . Out )
Get . Out is assigned to the parameter of Set. You’re referencing a parameter of Get without displaying the call. To read the Out parameter of Get requires a call and this call is implicitly made. In the text code line above you don’t see that Get is called. Get . Out is simply referenced. You can apply the same to diagram code:
Implicit call:
Note that the Exit Most Borders rule determines the direction.
You can see that the Out parameter of the Get command definition is referenced. This implicitly causes a call to Get. In explicit calls you reference the parameters of the command call, not the command definition.
######## Implicit Return Value Reference
<< implicit calls >>
Out is Get’s return value. Therefore, the identifier Get symbolizes the return value. In is a parameter of Set and you don’t necessarily need to mention its name in the parameter list. This all makes the text code:
Set ( Get )
Get’s symbolizing its return value can also be applied to diagram code:
Implicit return value reference, implicit call:
The line to Get is not really a line from an object to a command. The return value of Get is implicitly referenced.
The diagram above looks far simpler than the first diagram. So might the text code. In reality multiple steps are taken: • Call Get • Read Get . Out • Write Set . In, • Call Set.
In the diagram above, the return value is implicitly referenced by pointing to the command definition. You can also implicitly reference the return value by pointing to a command call square. That way, the call is explicit, but the return value reference is implicit.
Explicit call, implicit return value reference:
######## Multiple Out Parameters
######### Implicit Return Value Reference
<< return values >>
<< implicit calls >>
Implicit return value reference is only a way to reference the return value, not to the other out parameters. The other out parameters might be explicitly referenced.
Implicit return value reference, explicit out parameter reference:
######### Implicit Calls
<< implicit calls >>
When you reference output parameters of a command multiple times, each reference causes its own call to be made.
Two references to a parameter of the definition: two implicit calls:
If the diagram above is an abstract view on the system, there might only be made a single call, but officially the diagram above is showing two implicit calls. The meaning of the diagram above is:
< P: same system as above, now physically showing the two calls >
If you want to reference multiple output parameters of a single call, you might explicitly display the call and reference the objects that are inside the call symbol. By referencing the parameters of the call, you only use one call.
< Call in blue >
####### ? Referencing a Command Member
<< details >>
< 2008-10-08 Most of what is said in this section no longer applies, because a more explicit notation is desired, to make things less ambiguous, and some remarks have already been thought through and work differently. >
<< ? >>
Referencing a diamond’s members is like reading a command member.
<< implicit calls >>
< 20040418: this is interesting. It has to do with implicit call and I might explore in which situation this is useful. I think that when you call a member of the top circle, then the diamond executes. It’s like calling member of the bottom circle... >
It always happens just after the diamond executes.
<< creation behavior of commands >>
<< interpretation >>
< The parameter objects destroy right after the call. If you use the top circle like above, every consult of the top circle might result in executing the diamond again. To persist the information contained in the argument, without having to call the command again, you might do a State Copy. Another way of using output parameters is to give the execution a reference to an external symbol. Anyway: if you want return information to persist after the call, it has to be stored in external symbol: store the returned state to an object that the caller contains, or pass a reference to the caller’s object to the called command >
<< interpretation >>
< That’s true what I just said, but there’s nothing wrong with linking directly to the parameter and executing the command on each consult. There’s nothing wrong with that. The link might be something like consulting a property command in VB, a Get, which returns a reference to an object. Every time you consult the property, the command is launched again. That’s normal. >
< 2021-05-04: That last interpretation may be different if you might regard each diagram its own execution. Or when you might see the parameter line as a cloaked assignment call. >
<< details >>
< Might denote that the notation above is not an output situation. It’s an implicit call situation >
<< implicit calls >>
Oh, die assignments lijken afzonderlijke referenties, waardoor je implicit calls krijgt? Of is dat alleen bij referenties naar inhoud van squares?
Oh, nee! Hè! Ik heb ergens in dit hoofdstuk iets staan over een diamond die execute telkens als je een object met een line naar een parameter beraadslaagt. Hoe zit DAT dan?
Dat is verkeerd
>
<< implicit calls >>
Nice wording:
A reference to something inside a square causes an implicit call to the square, because the command is required to execute in order to reference something inside of it.
<< implicit calls >>
Implicit calls when referencing square contents (and their explicit diagram representations)
These seem fragments of an attempt to re-subdivide topics formerly inside the original Symbol documentation from 2004.
<< implicit calls >>
- Implicit call and Explicit call
- Implicit return value reference
<< parameter passing >>
- Out, In and Thru parameter usage
- Cover command reference too
<< execution flow >>- If example
<< implicit calls >>
- Initiation of execution:
- Containment in other diamond
- Consult of a parameter.
-
<< parameter passing >> -
Out, In and Thru
- Using reference parameters for in, out and thru (hard to control whether it’s in out or thru: you just use the object)
- Using State as In, Out and Thru
- Using a parameter’s line targets as Out
<< about other technology >>- Comparison with Com regarding returning object references.
- Persisting object reference (harder, is hardly done anyway. Or is it? Consider passing the returned object to another command)
- Using the command parameter as object reference directly
<< parameter passing >>- Command reference too
<< execution flow >>- If example
-
Execution Order
<< interpretation >>- Seeming randomly referencing diamond members.
<< ? >>- Initiation of execution:
- Containment in other diamond
- Consult of a parameter.
<< sequence order >>- Manual execution order
<< implicit calls >>
- Implicit Notations
- Implicit call and Explicit call
- Implicit return value reference
<< parameter passing >>
- Out, In and Thru
<< ? >>
- Execution Basics
<< ? >>
- Execution Order
<< implicit calls >>
- Implicit Notations
<< creation behavior of commands >>
- < > The assignment destination consult is not seen as a consult. < > Consult of a parameter as assignment destination might not require execution of the parameter holder.
- Executor represents one execution per call on definition.
- Implicit calls are not made for diamond contents reference < >
<< creation behavior of commands >>
<< interpretation of parameter connections >>
< 2008-10-08 This talks about parameter passing, a notation for value assignment and about implicit call. Those three might be spread over multiple documentation sections. But do the cross out here. >
In implicit argument assignment, there is no way to express state assignment.
If it were to become a connection between symbols, like implicit line assignments, it might definitely not behave the same as a line.
Implicit assignments:
De assignment calls gedragen zich niet normaal, want consult van de argumenten van A veroorzaken geen executie. Een soort passieve parameter consult vind plaats door de assignment calls, in het proloog van A. Bedenk wel: het zijn systeem commands: niet normaal.
De calls naar system commands gedragen zich anders dan gewone calls. Ze vinden namelijk hier plaats in het proloog van de executie. Je ziet dit wèl in de text code, maar hoe zie je in diagram code of een systeem commando apart wordt aangeroepen of in de context van een andere functie aanroep?
Hypothese: als je bij systeem commando aanroep een parameter betrekt in een diepere executie, dan zit het in het proloog of epiloog. Zit de parameter in de huidige of hogere executie, of is er helemaal geen parameter bij betrokken, dan wordt de systeem commando call normaal uitgevoerd. En veroorzaakt geen executie van de sub executor.
Niet het een executor, anders verwar je het met een aparte executie! Een system commando triggert geen executor:
* dit zou A triggeren als het niet een line van een system commando call was.
Assignment commands = system commands, eerste argument is het This argument.
* 2 consults, 1 execution. 1 executor zou er eigenlijk moeten zijn om 1 keer uitgevoerd te worden per ... definitie aanroep (afgezien van jumps) (? Hoe zit het daar dan precies mee)
Dus implicit call moet niet bestaan bij het referen naar diamond members. Dus dan heb je ook niet het probleem dat assignment calls speciaal geplaatst moeten worden in het proloog en epiloog: consult van diamond members vind altijd plaats in proloog of epiloog!
Oh jawel! Consult vind gewoonlijk altijd plaats in epiloog, maar bij assignment van argumenten consulteerd system commando de argument in proloog.
<< parameter passing >>- Using reference parameters for in, out and thru (hard to control whether it’s in out or thru: you just use the object)
- Using State as In, Out and Thru
- Using a parameter’s line targets as Out
<< other technology >>- Comparison with Com regarding returning object references.
- Persisting object reference (harder, is hardly done anyway. Or is it? Consider passing the returned object to another command)
- Using the command parameter as object reference directly
<< parameter passing >>- Command reference too
<< execution flow >>- If example
Different Wording, Not important, though
<< creation behavior of commands >>
<< nice wording >>
In an explicit call you always see the the call displayed as a separate diamond. If the call is made, the call is like a created object. After the call it is destroyed. When the call is created, you can reference its contents from anywhere without causing another call.
<< parameter passing >>
There are three types of parameters: in, out and thru. In parameters go in, out parameters go out and thru parameters come in and go out.
<< rule rich >>
<< interpretation issues >>
When pass an input parameter by value, it is guaranteed, that the operations inside the command might not affect the original object. < 2021-05-03: in VB.NET's ByVal parameter passing for reference types, the situation seem slightly more nuanced than that. >
<< details >>
In parameter passing By Value, the parameter object and the object, that is passed the value to or from, are not referring to each other at all.
<< about other technology >>
In some programming languages one use of by reference was to be able to pass large objects to a command. Another use was to be able to let the command have multiple return values, because in other programming languages a command might only have one return value.
<< details >>
A Value In parameter works best simple objects, that stores a single value,