IIf interface and implementation

[mdbs99]

Let's create a IIf interface to represents an inline condition. The basic implementation will be TIf class. I've been thinking to implement that using generics like that:

var
  Num: INumber;
begin
  Num :=
    TIf.New<INumber>(
      5 > 2,
      TInteger.New(5),
      TInteger.New(2)
    );
end;

[nunopicado]

I have one such interface and implementation, using generics. Your example would require some processing in either the constructor or the New function. It would also mean the interface would not have any methods. To avoid this, I've added a function Eval where the condition is analysed and the result returned.

Like this:

  IIF<T> = Interface
    function Eval: T;
  End;

and would be used like this:

var
  Num: INumber;
begin
  Num :=
    TIf<INumber>.New(
      5 > 2,
      TInteger.New(5),
      TInteger.New(2)
    ).Eval;
end;

If you find that acceptable, I can deal with this issue and make a PR with this code.

[mdbs99]

@nunopicado my mistake. I will put .Value but .Eval sounds good.

If you find that acceptable, I can deal with this issue and make a PR with this code.

Please, go ahead.

[heliosroots]

If we use "Mode Delphi" to maintain compatibility with generics in delphi.

Will not that force the use of "Mode Delphi" every time we want to use this implementation?

Can this conflict with another implementation in "Mode ObjFPC"?

[mdbs99]

@heliosroots a "mode" is used per unit. There is no conflict because we cannot have 2 modes at the same unit. But you can continue using "mode objfpc" in your own units without problems.

Thus, for we can have compatibility with Delphi, is mandatory to use mode delphi in all units of this project.

[nunopicado]

The "mode delphi" update will really be helpful if compatibility is to be maintained. Features like generics, anonymous and other are quite different between the two OP dialects, and their use without mode delphi would force even more conditional compilation. If the mode is per unit, I don't foresee any problems using it.

[mdbs99]

I don't know what is the FPC development status about anonymous, though. So let's use it as less as possible for now.

[heliosroots]

Complicated ... can have implementations in units that uses the "ObjFPC" mode and change to "Delphi" can break the code !!! It's a choice to make ...

[mdbs99]

But can break James code, not user code. Users (developers) can use whatever mode they want in their units.

[nunopicado]

@mdbs99 It's only an example! ;)

@heliosroots But you can mantain the ObjFPC in your code, thus not breaking any of your code. Only the project james itself would use mode delphi, and you can still access it from your mode ObjFPC project.

[heliosroots]

`Var L: specialize TFPGList; //legacy

I: IIf; //Possible implementation of james `

It can happen that this is in a unit of a project

[nunopicado]

hmmm Good point, I'll have to look into that to be sure.

[mdbs99]

@heliosroots in that case you can specialize types from James code... but I believe I didn't understand your point.

[heliosroots]

To specialize a type of JAMES, has this active the "Delphi" mode right?

Assuming that in the same unit you also need to specialize a type that is in "ObjFPC" mode, examples are implementations of the "FGL"

It's a choice to make ... or specialize in specializations ...

[mdbs99]

I don't have so much experience using generics so, forgive me if I say something wrong. Let's give an example: Look this code here. I specialized TFPGObjectList, right? Well, I belive that you can still using this sintaxe in objfpc mode files. Units that use mode delphi, I believe you can just remove the specialize keyword.

I will test this soon.

[heliosroots]

I was not sure, but I just tested the compiler that accepts compiling writing in one mode and specializing in another, so it's worth using delphi mode. He will not complain.

[mdbs99]

@nunopicado you can continue working on it, thanks.

[mdbs99]

About generics and compatibility with Delphi, you may take a look at this article.