0

I have been learning about OOP in Delphi. I noticed that sometimes within the class, a procedure is used even though a calculation is being made and it does not return a value, yet sometimes a value is returned. When should I do this, and when should I not?

In the below image, calAge is not returning a value.

image

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • I'm having a difficult time understanding what it is you want us to tell you. Also, please don't post links to off-site resources. And definitely don't post screenshots of your code. Please just copy the raw code here, and use the code formatting option. It works relatively well. – Jerry Dodge Jan 21 '17 at 05:11
  • What did your instructor say when you asked this question during class? – Rob Kennedy Jan 21 '17 at 07:49
  • What @RobKennedy says. Also has your instructor told you about the hints and warnings Delphi's compiler emits during a compilation? In the IDE, go to Project | Options and see the Compiler Messages tab in the pop-up. – MartynA Jan 21 '17 at 08:33
  • There is a difference between functions and procedures in Delphi. Here's something to read: http://www.delphibasics.co.uk/Article.asp?Name=Routines – renevondecafe Jan 21 '17 at 09:20
  • Every object has internal state. In order to "ask" an object for such state you would use functions in Delphi world; how do you mutate that state? Thats where procedures come in. So, basically you give some order to an object and then if you need to, you ask "what's your new state". "Questions" (aka functions) should not change the inner state, iow, asking the question does not change the answer – Agustin Ortu Jan 21 '17 at 18:57
  • Do **NOT** post images of your code here. Delphi source code is text, and that's how it belongs in your question here, as text, properly formatted as code. See [this Meta post](http://meta.stackoverflow.com/a/285557/62576) for a list of the many reasons **not** to post images unless absolutely necessary. – Ken White Jan 21 '17 at 21:08

1 Answers1

1

What may be confusing you is that the code of that function, Tschool.Accepted is obviously incomplete; a value is assigned to the result value of the function if the if statement is true, but not otherwise. That's actually a programming error, because it means that the result value is undefined if the if statement returns false.

Put another way, what's wrong with Tschool.Accepted is that it breaks the fundamental rule that every execution path through the function should result in the function's result being assigned a value. As written, Tschool.Accepted breaks the rule because it doesn't get a result value assigned if the if ... condition is false.

So, one way to correct the programming error is to add an else clause to the end of the if ... statement, e.g.

if (Some conditions are true) then
  Result := True
else
  Result := False;

Another way, which is slightly inefficient but covers all bases, is to assign a predefined value to Result as the first statement in the function and then assign another value to Result later on in the function's code if some condition(s) applies.

Btw, because Tschool.Accepted is a Boolean function, you can avoid writing an if ... else ... by using a single assignment statement like this

function Tschool.Accepted : Boolean;
begin
  Result := (fdeposit) and (fAge >= 4) and (fAge <= 6);
end;

because what's on the righthand side of the assignment is an expression of Boolean type.

In Delphi, there are often situations where execution of some code doesn't result in a useful (or interesting) value. Those are written as procedures rather than functions. So, one answer to your q is that if a method of an object can usefully return a value, write it as a function, otherwise write it as a procedure and if you write it as a function, make sure that it returns a value for any execution path through it.

MartynA
  • 30,454
  • 4
  • 32
  • 73
  • @DavidHeffernan: Thanks for the correction, I have taken the final para out. I will try and remind myself where I got the idea from in the first place. – MartynA Jan 22 '17 at 08:50