Talk:Methods - Revision history

NMichell at 22:14, 29 August 2016

2016-08-29T22:14:41Z

← Older revision		Revision as of 22:14, 29 August 2016
Line 45:		Line 45:

	Thanks		Thanks


			:Hi Alex,

			:Yes - removing the references to class variables would clear the waters.

			:As an aside, the standard that's now evolved here is to name parameters %i.xyz, %o.abc etc. This serves both to identify them as parameters and as inputs or outputs.

			:NMichell

			:e: nickmichell@gmail.com

JAL: /* Response */ misc formatting

2016-08-29T20:05:41Z

Response: misc formatting

← Older revision		Revision as of 20:05, 29 August 2016
Line 37:		Line 37:
	Nick,		Nick,

	I think you're correct that the explanation is a bit confusing – maybe too clever by a half. I think the reason DHS requested this feature is so they could refer to parameters in the code as <~~var~~>%parm.whatever</~~var~~> but not put the <~~var~~>parm.</~~var~~> part in the method template. This was especially important for named parameters where it would have been dumb to do stuff like:		I think you're correct that the explanation is a bit confusing – maybe too clever by a half. I think the reason DHS requested this feature is so they could refer to parameters in the code as <code>%parm.whatever</code> but not put the <code>parm.</code> part in the method template. This was especially important for named parameters, where it would have been dumb to do stuff like:
	<p class="code">%foo:method(parm.x=%x, parm.y=true)		<p class="code">%foo:method(parm.x=%x, parm.y=true)
	</p>		</p>
	I think I'd avoid discussing private/public variables altogether here as I think it's a red herring. Certainly one can have a private or public variable called <~~var~~>petrol</~~var~~> and while one <b>can</b> refer to it as <~~var~~>%petrol</~~var~~> in class code, I always advocate using <~~var~~>%this:petrol</~~var~~>. In such a case, if there is a local variable called <~~var~~>%petrol</~~var~~> the only way one can get at the class variable is ~~via~~ <~~var~~>%this:petrol</~~var~~>. This is pretty standard O-O stuff and is the way Java, C++, and other "traditional" O-O languages work.		I think I'd avoid discussing private/public variables altogether here as I think it's a red herring. Certainly one can have a private or public variable called <code>petrol</code>, and while one <b>can</b> refer to it as <code>%petrol</code> in class code, I always advocate using <code>%this:petrol</code>. In such a case, if there is a local variable called <code>%petrol</code>, the only way one can get at the class variable is with <code>%this:petrol</code>. This is pretty standard O-O stuff, and it is the way Java, C++, and other "traditional" O-O languages work.

	Sound reasonable? If so, we'll fix.		Sound reasonable? If so, we'll fix.

	Thanks		Thanks

Alex at 17:47, 29 August 2016

2016-08-29T17:47:11Z

← Older revision		Revision as of 17:47, 29 August 2016
Line 1:		Line 1:
			==Comment==
	I landed on this page to discover more about the InternalNames block so I’m hesitant to perform an Edit in case I’ve misunderstood it.		I landed on this page to discover more about the InternalNames block so I’m hesitant to perform an Edit in case I’ve misunderstood it.

Line 32:		Line 33:

	e: nickmichell@gmail.com		e: nickmichell@gmail.com

			==Response==
			Nick,

			I think you're correct that the explanation is a bit confusing – maybe too clever by a half. I think the reason DHS requested this feature is so they could refer to parameters in the code as <var>%parm.whatever</var> but not put the <var>parm.</var> part in the method template. This was especially important for named parameters where it would have been dumb to do stuff like:
			<p class="code">%foo:method(parm.x=%x, parm.y=true)
			</p>
			I think I'd avoid discussing private/public variables altogether here as I think it's a red herring. Certainly one can have a private or public variable called <var>petrol</var> and while one <b>can</b> refer to it as <var>%petrol</var> in class code, I always advocate using <var>%this:petrol</var>. In such a case, if there is a local variable called <var>%petrol</var> the only way one can get at the class variable is via <var>%this:petrol</var>. This is pretty standard O-O stuff and is the way Java, C++, and other "traditional" O-O languages work.

			Sound reasonable? If so, we'll fix.

			Thanks

NMichell: InterNames

2016-08-29T03:05:21Z

InterNames

New page

I landed on this page to discover more about the InternalNames block so I’m hesitant to perform an Edit in case I’ve misunderstood it.

It seems to me that the example given in this article is confusing: -

subroutine add(%petrol is float nameRequired optional, -
%oil is float nameRequired optional)
internalNames
%parm.petrol is %petrol
%parm.oil is %oil
end internalNames
...
%petrol = %petrol + %parm.petrol
%oil = %oil + %parm.oil

Surely something like...

<I>%parm.petrol = %valueToBeReturnedToCaller</I>

...would make more sense.

The explanation that follows the example compounds the problem: -

<I>This example illustrates how if petrol and oil were private class variables, the InternalNames block makes it possible to have parameters in a method declaration with the same name, but to avoid naming conflict or confusion between the private class variables and the parameter names.</I>

As I write this, I wonder if the situation envisaged is where the private class has a %petrol variable and the parameter name-mapping is to allow that to be distinct from the %petrol parameter. Hhmmm - that code needs a rewrite.

Happy to be corrected if I’ve missed a trick.

NMichell

e: nickmichell@gmail.com