#204 Type checking and type casting issue

[QUASAR research group]

-- Consider the attached classic Royal&Loyal model where classes Earning and Burning inherit from the abstract class Transaction. CustomerCard is associated with Transaction (association role "transactions"). A soil file is also attached.

open -q objectsData.soil
? Transaction.allInstances
-> Set{burn1,burn2,earn1,earn2} : Set(Transaction)
-- OK

? Transaction.allInstances->select(oclIsTypeOf(Earning))
-> Set{earn1,earn2} : Set(Earning)
-- The return type shoudn't be Set(Transaction), since the select operation does not cause any casting?
-- I know it is correct "inside" since if we try to apply some operation or access some atribute specific to Earning or Burning we get an error, unless we perform a type cat with oclAsType(...)

? Transaction.allInstances->select(oclIsTypeOf(Earning)).doEarn()
<input>:1:55: Undefined operation `Transaction.doEarn' in shorthand notation for collect.
-- OK

? Transaction.allInstances-> select(oclIsTypeOf(Earning)).oclAsType(Earning).doEarn()
-> Bag{'20000 earned!','25000 earned!'} : Bag(String)
-- OK

[QUASAR research group]

This is not exactly a bug, but more a representation issue that happens whe we perform a select to obtain objects of a subclass. The problem is that for somophors it is hard to understand why they cannot apply directly an operation of the subclass to the returned set, since the returned type that appears in USE is a Set of the subtype, when in fact is a Set of the base class.