[fpc-devel] problem with "is" operator

[Linuxer Wang]

Uberto Barbini wrote:

>>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.
>
>  
>
>>>TCircle.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"
>>>      
>>>
>>The type of inst needs to be a class type (such as TFigure above), not
>>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).
>  
>
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.
What you said maybe true in design patterns, but not so true in language 
sematics.

>
>Bye Uberto
>
>_______________________________________________
>fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
>  
>