From: Craig Chambers (chambers@cs.washington.edu)
Date: Fri Feb 07 2003 - 18:11:26 PST
Vassily Litvinov wrote:
> I wonder if Andrei's AnalysisAction is a concrete object (as otherwise
> it's hard to pass it around). If so, type synonyms are not going to help.
They help fine, because a concrete object is a synonym for a concrete
representation and a type. As long as he wants to use the type version of the
AnalysisAction (which is all I've needed to do with my other AnalysisAction
synonyms), then things are fine.
Although maybe by concrete you mean Cecil concrete. He's not trying to pass
around a concrete (singleton) object, he's trying to (mainly return) a value
that's a subtype of the type AnalysisAction[...].
>
> But in this case there is a more general question of whether concrete
> objects are allowed to have type parameters, in the first place. As
> otherwise the fields of this object could be viewed of different types
> (for those fields whose types refer to the type parameters), which is
> unsound.
>
> In other words, AnalysisAction[CSELatticeElmt, ForwardCFGAnalysisGraph]
> and AnalysisAction[CSELatticeElmt, BackwardCFGAnalysisGraph] would need to
> be different concrete objects.
Interesting issue. I suspect there should be some sort of ITC that ensures that
no concrete parameterized object implements or inherits a field whose type
references one of the parameters.
>
> Just wondering.
> Vass
>
> _______________________________________________
> Cecil mailing list
> Cecil@cs.washington.edu
> http://mailman.cs.washington.edu/mailman/listinfo/cecil
-- Craig
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://mailman.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2.1.5 : Fri Feb 07 2003 - 18:11:32 PST