Procedures/Functions can have default values for arguments, so they don't need to be specified if called

  function GetFoo(Bar: integer; XY: Boolean = True): Integer;

Properties (indexed) don't have such a syntax:

  property Foo[Bar: integer; XY: Boolean = True] read GetFoo;

will give an error

However the follwing Syntax compiles fine:
  function GetFoo(Bar: integer; XY: Boolean = True): Integer;
  property Foo[Bar: integer; XY: Boolean] read GetFoo;
and then you can do:
  a := Object.Foo[1];

But:
Is that supposed to work?

Because it can not be done for write access, as the last argument it the value to be assigne, and that doesn't have a default value. And even if it had, it requred the correct position => that is *all* param present.

Martin

No, it is not. It is a compiler bug. Could you please create a bug report?

Michael.

Done.

However it would be nice to have a feature like

    property Foo[Index: Integer]: Integer  write SetFoo  read GetFoo;
    property Foo[Index: Integer; Ask: Boolean]: Integer  write
SetFooAsk   read GetFooAsk;

The must have different Method Names, because the Setters(write SetFoo) last argument is the Value, so it' can not have a optional Ask element:

  procedure WrongSetFoo(Index: Integer; Ask: Boolean= True; AValue:

Integer);
But with different Setter/Getters that would not be a problem. In fact they can have the same name, if they are overloaded.

Any idea if such a feature would have a chance?

Best Regards
Martin

It won't: http://bugs.freepascal.org/view.php?id=12737 (that feature request was about having getters/setters with the same name, but the core problem is having multiple properties with the same name).

Jonas

As far as I know, delphi 2005 and up allow the problem in 12737 for non-published properties. Since array properties cannot be published anyway, the argument with RTTI is void ?

(which doesn't mean there are no other arguments to prevent it's implementation)

Michael.

Other arguments are also mentioned in the bug report (including about only allowing it for non-published properties). The fact that Delphi allows it is obviously a strong argument in favour of allowing it anyway.

Jonas

I would think it is a natural extension of procedural overloading ? An array property is only a simplification of getter/setters...

That it is impossible to do for published properties is not abnormal either: there are other kinds of properties that cannot be published. (records for one).

I'll file a separate bugreport with the request to allow property overloading for non-published array properties if you think it is better. (I do ;) )

Michael.

Op Thu, 11 Jun 2009, schreef Michael Van Canneyt:

On Thu, 11 Jun 2009, Jonas Maebe wrote: > I would think it is a natural extension of procedural overloading ?

It's not that simple. Properties can be both hidden variable access as well as procedure access. Variable overloading is not allowed, because it causes a lot of issues, i.e.:

var a:word;
     a:char;
begin
   a:=1;
   a:='!';
   writeln(a); {what does this mean??}
end;

Property overloading gets you the same issues, i.e. in the example above you could replace both variables with properties and answer the same question.

Considering this, I do not think it can considered a logical extension of procedure overloading.

Daniël

Stop:

It's only for indexed properties, not for normal properties. The index type uniquely determines which one you want. Just as in a procedure, the argument type determines which one you want.

Michael.

Good point.

However the example above (even so you use the setter [assign to the property] instead of reading), is the same as overloading *functions* by result.
You can not overload functions by result; still you can overload them by arguments.

So consistency of overloading functions is *not* defined by being able to use every bit of information on the function for the overloading; but only selected (the parameters passed to the function).

On properties this question was about the index given to a property (number and type of indexes). I do agree, it can not be about the type of the property itself.

Martin