A Theory of Objects, 1996. ,
DOI : 10.1007/978-1-4419-8598-9
The Fortress Language Specification, version 0, 2005. ,
Subtyping for Extensible, Incomplete Objects, Fundamenta Informaticae, vol.38, issue.4, pp.325-364, 1999. ,
URL : https://hal.archives-ouvertes.fr/hal-01153734
Obliq: A Language with Distributed Scope, Computing Systems, vol.8, issue.1, pp.27-59, 1995. ,
DOI : 10.1145/199448.199516
URL : http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.187.4687
Traits, ACM Transactions on Programming Languages and Systems, vol.28, issue.2, pp.331-388, 2006. ,
DOI : 10.1145/1119479.1119483
URL : https://hal.archives-ouvertes.fr/inria-00403568
A Lambda Calculus of Objects and Method Specialization, Nordic Journal of Computing, vol.1, issue.1, pp.3-37, 1994. ,
Statically Typed Traits. http://www.cs. uchicagopdf. The early version " A Typed Calculus of Traits " has been presented at FOOL 10, 2004. ,
Classes and mixins, Proceedings of the 25th ACM SIGPLAN-SIGACT symposium on Principles of programming languages , POPL '98, pp.171-183, 1998. ,
DOI : 10.1145/268946.268961
Featherweight Java: a minimal core calculus for Java and GJ, ACM Transactions on Programming Languages and Systems, vol.23, issue.3, pp.396-450, 2001. ,
DOI : 10.1145/503502.503505
URL : http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.1141
FeatherTrait, ACM Transactions on Programming Languages and Systems, vol.30, issue.2 ,
DOI : 10.1145/1330017.1330022
URL : https://hal.archives-ouvertes.fr/inria-00432540
The Definition of Standard ML (Revised), 1997. ,
Flattening Traits., The Journal of Object Technology, vol.5, issue.4, 2006. ,
DOI : 10.5381/jot.2006.5.4.a4
Java Traits ? Improving Opportunities for Reuse, 2004. ,
Traits -Composing Classes from Behavioral Building Blocks, 2005. ,
Traits: Composable Units of Behaviour, Proc. of ECOOP, pp.248-274, 2003. ,
DOI : 10.1007/978-3-540-45070-2_12
Typed Traits in Java, Proc. of ECOOP, pp.453-478, 2005. ,
Inheritance and the Development of Encapsulated Software Systems, Research Directions in Object-Oriented Programming, pp.165-188, 1987. ,
Self: The Power of Simplicity, Proc. of OOPSLA, pp.227-241, 1987. ,
? If m ? ?TA, then there is an unique TA i ? TA where altlook(m, TA i ) = fail. ? If m ? ?TA, then, since C i is well-typed, the rule (Cla·Ok) enforces that m ? ?TA. Then, for all TA i ? TA, we have m ? meth(TA i ) ? m in TA i n in TA 1 . Moreover, we know that n ? meth(TA 1 ), by Lemma 1, which means that there is at least one altlook(n, TA 1 ) = I n (I x){. . .} which is derivable, by Lemma 4. Thus, altlook(m, TA i ) = I m (I x){. . .} is derivable, for all TA i such that m ? meth i ) is a function, Which ensures they are all equal ,
Proof Straightforward induction on the derivation of msig(m, TA) = S. Here are the most relevant cases: ? (MSig·Ali 2 ) In both rules (Alias·Ok 1 ) and (Alias·Ok 2 ), it is easy to observe that the new name of the method is not in the requires list (the role of (Alias·Ok 2 ) is actually to remove it from the requires list if it appears in the previous step) Hence the result, Lemma, vol.8 ,
)) = I ? I, then mtype(m, TA) = I ? I ,
Since TA typechecks, then altlook(m, TA 1 ) = fail, by Lemma 4 We also have, by definition of altlook, that altlook(m, TA) = fail. By definition of mtype, we have that mtype(m, TA) is inferred from msig(m, TA) (rule (MTyp·Virt)), and that mtype(m, TA 1 ) is inferred from altlook(m 1 ) = I ? I, 1 ) (rule (MTyp·Impl)). By rule (MSig·Ex 1 ), we have mtype(m ,