Talk:Methods

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.

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...

%parm.petrol = %valueToBeReturnedToCaller

...would make more sense.

The explanation that follows the example compounds the problem: -

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.

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

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 %parm.whatever but not put the parm. part in the method template. This was especially important for named parameters, where it would have been dumb to do stuff like:

%foo:method(parm.x=%x, parm.y=true)

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 petrol, and while one can refer to it as %petrol in class code, I always advocate using %this:petrol. In such a case, if there is a local variable called %petrol, the only way one can get at the class variable is with %this:petrol. 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.

Thanks