Methods - Revision history

Alex: /* Optional and default parameters */

2019-10-25T21:55:49Z

Optional and default parameters

← Older revision		Revision as of 21:55, 25 October 2019
Line 264:		Line 264:
	...		...
	%pie = new('31415929') </p>		%pie = new('31415929') </p>

			Before Model 204 V7.8, output parameters could not be optional or have default values. In Model 204 V7.8, output parameters can be specified as <var>Optional</var> and a default value could be specified with <var>Default</var>. One related change is that if a <var>Len</var> value is specified with <var>Optional</var> or <var>Default</var> <var>Output</var>, it indicates the length of the hidden target for the output parameter if none was passed. For all other <var>Output</var> paranmeters, <var>Len</var> is meaningless, just as it was before Model 204 V7.8. The following is an example of the use of an optional output parameter:
			<p class="code">function getRemote( -
			%target is string len 32, %errorReason is string len 80 optional output -
			) is float
			...
			</p>
			In this example, if <code>%errorReason</code> is not specified in a call and then set to a value longer than 80 bytes it wil be truncated to 80 bytes. However, if a string of a different length is passed, the length of that string determines truncation behavior.

	===<b id="isPresent"></b>Is [Not] Present test for optional or default parameter===		===<b id="isPresent"></b>Is [Not] Present test for optional or default parameter===

ELowell: /* Mapping parameter names in declarations to names within the method */

2019-09-18T18:24:53Z

Mapping parameter names in declarations to names within the method

← Older revision		Revision as of 18:24, 18 September 2019
Line 465:		Line 465:

	<p class="code">%multipla:fill(oil=0.5)</p>		<p class="code">%multipla:fill(oil=0.5)</p>
	===<b id="intNamesStmt"></b>Mapping parameter names in declarations to names within ~~the method~~===		===<b id="intNamesStmt"></b>Mapping parameter names in declarations to names within methods===
	It is possible that the ideal names for method declarations are not the ideal names for the parameters within the actual methods themselves. For example, one might have a standard that all parameters should start with <code>parm.</code> in method code, so that it is easy to tell which variables are parameters. If this standard is extended to the names on the declaration, the result is ugly and redundant parameter names in declarations and method invocations:		It is possible that the ideal names for method declarations are not the ideal names for the parameters within the actual methods themselves. For example, one might have a standard that all parameters should start with <code>parm.</code> in method code, so that it is easy to tell which variables are parameters. If this standard is extended to the names on the declaration, the result is ugly and redundant parameter names in declarations and method invocations:

ELowell: /* InternalNames - map parameter names to names within the method */

2019-09-18T18:21:49Z

InternalNames - map parameter names to names within the method

← Older revision		Revision as of 18:21, 18 September 2019
Line 465:		Line 465:

	<p class="code">%multipla:fill(oil=0.5)</p>		<p class="code">%multipla:fill(oil=0.5)</p>
	===<b id="intNamesStmt"></b>~~InternalNames - map~~ parameter names to names within the method===		===<b id="intNamesStmt"></b>Mapping parameter names in declarations to names within the method===
	It is possible that the ideal names for method declarations are not the ideal names for the parameters ~~inside~~ the actual methods themselves. For example, one might have a standard that all parameters should start with <code>parm.</code> in method code, so that it is easy to tell which variables are parameters. If this standard is extended to the names on the declaration, the result is ugly and redundant parameter names in declarations and method invocations:		It is possible that the ideal names for method declarations are not the ideal names for the parameters within the actual methods themselves. For example, one might have a standard that all parameters should start with <code>parm.</code> in method code, so that it is easy to tell which variables are parameters. If this standard is extended to the names on the declaration, the result is ugly and redundant parameter names in declarations and method invocations:

	<p class="code">%multipla:fill(parm.oil=0.5)</p>		<p class="code">%multipla:fill(parm.oil=0.5)</p>

	The <var>InternalNames</var> block is provided to allow mapping of parameter names on declarations to another name to be used ~~inside~~ the method, making it possible to use the optimal names on method declarations and ~~inside~~ methods, even if the two names are not the same.		The <var>InternalNames</var> block is provided to allow mapping of parameter names on declarations to another name to be used within the method, making it possible to use the optimal names on method declarations and within methods, even if the two names are not the same.

	The syntax of the <var>InternalNames</var> block is:		The syntax of the <var>InternalNames</var> block is:

ELowell: /* The InternalNames block - map argument names to names internal to the method */

2019-09-18T18:16:43Z

The InternalNames block - map argument names to names internal to the method

← Older revision		Revision as of 18:16, 18 September 2019
Line 465:		Line 465:

	<p class="code">%multipla:fill(oil=0.5)</p>		<p class="code">%multipla:fill(oil=0.5)</p>
	===<b id="intNamesStmt"></b>~~The~~ InternalNames ~~block~~ - map ~~argument~~ names to names ~~internal to~~ the method===		===<b id="intNamesStmt"></b>InternalNames - map parameter names to names within the method===
	It is possible that the ideal names for method declarations are not the ideal names for the parameters inside the actual methods themselves. For example, one might have a standard that all parameters should start with <code>parm.</code> in method code, so that it is easy to tell which variables are parameters. If this standard is extended to the names on the declaration, the result is ugly and redundant parameter names in declarations and method invocations:		It is possible that the ideal names for method declarations are not the ideal names for the parameters inside the actual methods themselves. For example, one might have a standard that all parameters should start with <code>parm.</code> in method code, so that it is easy to tell which variables are parameters. If this standard is extended to the names on the declaration, the result is ugly and redundant parameter names in declarations and method invocations:

Dme: /* Internal parameter names */

2019-09-17T19:45:03Z

Internal parameter names

← Older revision		Revision as of 19:45, 17 September 2019
Line 453:		Line 453:
	</p>		</p>

	==Internal parameter names==		==<b id="Internal parameter names"></b>Parameter description guidelines==
	A method declaration contains a description of method parameters. A parameter description includes the parameter name, type, and attributes (<var>Optional</var>, <var>AllowNull</var>, and so on). The names should be descriptive, as this makes it easier for users of a method to understand what the method does by looking at its declaration. For example, the following method declaration		A method declaration contains a description of the method's parameters. A parameter description includes the parameter name, type, and attributes (<var>Optional</var>, <var>AllowNull</var>, and so on). The names should be descriptive, as this makes it easier for users of a method to understand what the method does by looking at its declaration. For example, the following method declaration

	<p class="code">subroutine fill(%petrol is float, %oil is float)</p>		<p class="code">subroutine fill(%petrol is float, %oil is float)</p>
Line 465:		Line 465:

	<p class="code">%multipla:fill(oil=0.5)</p>		<p class="code">%multipla:fill(oil=0.5)</p>
			===<b id="intNamesStmt"></b>The InternalNames block - map argument names to names internal to the method===
	It is possible that the ideal names for method declarations are not the ideal names for the parameters inside the actual methods themselves. For example, one might have a standard that all parameters should start with <code>parm.</code> in method code, so that it is easy to tell which variables are parameters. If this standard is extended to the names on the declaration, the result is ugly and redundant parameter names in declarations and method invocations:		It is possible that the ideal names for method declarations are not the ideal names for the parameters inside the actual methods themselves. For example, one might have a standard that all parameters should start with <code>parm.</code> in method code, so that it is easy to tell which variables are parameters. If this standard is extended to the names on the declaration, the result is ugly and redundant parameter names in declarations and method invocations:

DCameron: /* Property */

2018-07-18T13:05:35Z

Property

← Older revision		Revision as of 13:05, 18 July 2018
Line 119:		Line 119:
	%this:celsius = (%fahrenheit - 32) / 1.8		%this:celsius = (%fahrenheit - 32) / 1.8
	end set		end set
	end property fahrenheit		end property fahrenheit
	end class		end class

DCameron: /* Property */

2018-07-18T13:04:14Z

Property

← Older revision		Revision as of 13:04, 18 July 2018
Line 123:		Line 123:

	%temp is object thermometer		%temp is object thermometer
			%temp = new
	...		...
	%temp:fahrenheit = %input		%temp:fahrenheit = %input

Adrian: /* Named parameters */

2018-02-01T14:21:50Z

Named parameters

← Older revision		Revision as of 14:21, 1 February 2018
Line 437:		Line 437:
	<p class="code">$setg('CRN', %value=%crn)		<p class="code">$setg('CRN', %value=%crn)
	</p>		</p>
	If code>%value</code> or <code>%crn</code> were not defined, this statement would generate a compilation error.		If <code>%value</code> or <code>%crn</code> were not defined, this statement would generate a compilation error.

	Given this syntactic structure, one might expect that a named argument in a method invocation would be interpreted as a comparison of a field name with a value. For example, one might expect the argument to the <var>New</var> method to be the result of a comparison between field <code>Host</code> and the variable <code>%target</code>:		Given this syntactic structure, one might expect that a named argument in a method invocation would be interpreted as a comparison of a field name with a value. For example, one might expect the argument to the <var>New</var> method to be the result of a comparison between field <code>Host</code> and the variable <code>%target</code>:

Dme: /* Optional and default parameters */

2017-06-21T14:48:36Z

Optional and default parameters

← Older revision		Revision as of 14:48, 21 June 2017
Line 177:		Line 177:
	</p>		</p>

	==Optional and default parameters==		==<b id="optionalParams"></b>Optional and default parameters==
	Methods support optional parameters, that is, parameters that do not need to be passed on every invocation of the method. For example, suppose a function returns the number of items in a bin. And suppose that function can be passed a number of items to add to the bin. Usually when the function is invoked, no items are added, but once in a while, they are. So the function can be declared as follows:		Methods support optional parameters, that is, parameters that do not need to be passed on every invocation of the method. For example, suppose a function returns the number of items in a bin. And suppose that function can be passed a number of items to add to the bin. Usually when the function is invoked, no items are added, but once in a while, they are. So the function can be declared as follows:

Line 263:		Line 263:
	...		...
	%pie = new('31415929') </p>		%pie = new('31415929') </p>

			===<b id="isPresent"></b>Is [Not] Present test for optional or default parameter===

	Generally, it is sufficient for a method to simply use the replacement value for an optional or default parameter without caring whether that value was specified explicitly or generated implicitly. For example, if a method is declared as follows:		Generally, it is sufficient for a method to simply use the replacement value for an optional or default parameter without caring whether that value was specified explicitly or generated implicitly. For example, if a method is declared as follows:

JAL: misc formatting

2016-08-30T17:59:28Z

misc formatting

Show changes