Uberto Barbini wrote:
I don't agree with you fully. Let's have a look at java, its "instanceof" semantic is complete. But the "is" semantic of FPC is not complete.It does not seem right to declare var inst: TMyInterface if you want inst to have circles and squares as values. I would expect that you also have a class TFigure, of which TCircle and TSquare both are descendants. These could also implement TMyInterface.
You then declare var inst: TFigure and can do inst := TCircle.Create.
If so, why bother with Interfaces?
You need interfaces exactly when you cannot define a common ancestor for two classes with similar behavior.
The classical example is IFly implented by TBat and TSwallow.
The type of inst needs to be a class type (such as TFigure above), notTCircle.Create. How can I know which instance is inst? The following code can not even compile:
if inst is TCircle then ...
class type expected, but got "TMyInterface"
Incompatible type for arg no. 2: Got "TMyInterface", expected "TObject"
an interface object type. If you do as I suggest above, it should work.
if inst is TCircle then ...
I don't think this can possibly work in fpc or Delphi. Apart tecnical problems, it'd be plainly wrong: using interfaces you lost the rights to know the original class.
Sometimes I added a GetUnderObject() to my interfaces to get the actual object. But it's a choice up to the interface author.
BTW I needed it to release the object through the interface.
I suspect that if you shouldn't ever need to know the actual class when using interfaces (maybe apart debug reasons).
What you said maybe true in design patterns, but not so true in language sematics.
Bye Uberto
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
