[fpc-pascal] methods of an object to create others objects

spir denis.spir at gmail.com
Tue Jul 6 08:05:35 CEST 2010

On Mon, 5 Jul 2010 16:51:54 -0300
Marcos Douglas <md at delfire.net> wrote:

> >> Why I ask this:
> >> If not exists the variable obj2 in call obj1.createObj will happen a
> >> memory leak, right? Because there is not variable to release.
> >
> > Do you mean using a function as a statement? (for its so-called "side effect")
> > *This*, in my opinion, is very bad programming practice. But it's just an opinion.
> > First, a function that has effects is already bad, except for recording data
> > on the object (eg metadata, or memoization).
> What do you mean "a function has effects is already bad"?
> A function/procedure always has effects, don't?

A question of terminology. "Effect" usually means the changes a "routine" (function or procedure) lets once it has completed its task. Indeed, any routine can do changes, but we can make a difference between changes in routine's own local scope (usually on the stack) that disappear, and changes on the outer worlds that remain. The latter are called effect and are the purpose of procedures. (Hope I'm clear ;-)
A function's purpose is to construct and return a given value.  For instance the purpose of parser.getLine(source, pos) is seemingly clear; if it does an effect in addition to returning lines, then this effect is called "side-effect" because this is often considered bad practice.
There are good reasons for this, mine are:
* This is misleading: nothing in the apparent purpose of the func, and in its name, lets guess that there are permanent changes in the world's state.
* It makes it hard to reason about the program.
* It kills formal properties of functions that could be used to prove. For instance, the same func called twice with the same arguments may not return the same result.

> > Second, if you really want it to *do*
> > something in addition to *making* its return value, you should make this "anomaly"
> > obvious by writing the effect in an external proc (called by the func). So that, when you
> >  need the effect but not the value, just call the proc.
> Well... I think something is smell bad with this code :)
> But I will try a better example:
> Imagine a text file. Each line correspond an object. A parser creates
> these objects. So, in a loop:
> for I := 0 to Lines.Count-1 do
> begin
>   line := Lines[I];
>   //(...)
>   obj := Parser.GetObj(line);
>   try
>     //(...)
>   finally
>      obj.Free;
>   end;
> end;
> The object Parser creates obj through the line string.
> If the *line* is broke, Parser do not can create an object and an
> Exception is created; the *obj* never is nil because there are
> exception handling.

I do not see the problem, since obj is explicitely free'ed...

> Marcos Douglas


vit esse estrany ☣


More information about the fpc-pascal mailing list