plan of the talk
DESCRIPTION
Flattening versus Direct semantics for Featherweight Jigsaw Giovanni Lagorio , Marco Servetto and Elena Zucca. Plan of the talk. Flattening and Direct semantics By example: Inheritance Featherweight Jigsaw ( FJig ) (nice and clean) surface syntax Generalized inheritance - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/1.jpg)
Flattening versus Direct semantics for Featherweight Jigsaw
Giovanni Lagorio, Marco Servetto and Elena Zucca
![Page 2: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/2.jpg)
Plan of the talk Flattening and Direct semantics
By example: Inheritance Featherweight Jigsaw (FJig)
(nice and clean) surface syntax Generalized inheritance
I’ll gloss over its (ugly but equivalent) core syntax
Conclusions
![Page 3: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/3.jpg)
Flattening Semantics
![Page 4: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/4.jpg)
The intuition of Inheritance Please think how you’d explain inheritance
to a muggle1
(1 here, indicates someone who’s never heard of OO)
Odds are you’re thinking of flattening semantics
![Page 5: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/5.jpg)
Flattening Semantics of inheritanceclass C1 { void m1() {…}}class C2 extends C1 { void m2() {…}} It’s as we
wrote C2 like this
class C2 { void m1() {…} void m2() {…}}
What does this mean?
![Page 6: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/6.jpg)
ExtendedLanguage
The general idea Giving semantics of some feature by
translating it away Programs translated in (equivalent) programs
that don’t use the feature
Language
class C2 extends C1 { void m2() {…}}
class C2 { void m1() {…} void m2() {…}}
Extension flattened into the vanilla language
Let’s see pros and cons
![Page 7: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/7.jpg)
Pros: it’s intuitive class C1 { void m1() {…}}
class C2 extends C1 { void m2() {…}}
class C3 extends C2 { void m3() {…}}
class C1 { void m1() {…}}class C2 { void m1() {…} void m2() {…}}
class C3 { void m1() {…} void m2() {…} void m3() {…}}
![Page 8: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/8.jpg)
Pros: good old method lookupclass C1 { void m1() {…}}class C2 { void m1() {…} void m2() {…}}class C3 { void m1() {…} void m2() {…} void m3() {…}}
Lookup as easy as it can get
No changes in the definition (the program changes, not lookup)
For instance,lookup(C2, …)=
(inheritance has been flattened out)
![Page 9: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/9.jpg)
class C1 { void m1() {…}}
class C2 extends C1 { void m2() {…}}
class C3 extends C2 { void m3() {…}}
Cons: compiling dependenciesclass C1 { void m1() {…}}class C2 { void m1() {…} void m2() {…}}class C3 { void m1() {…} void m2() {…} void m3() {…}}
the binarydepends on
![Page 10: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/10.jpg)
Flattening Semantics, recap Intuitive: good tool for
teaching/understanding Been used to give the semantics of
mixins, traits, …but
Poor implementation choice Lot of compiling dependencies (unlike Java,
like C++) Code bloating
![Page 11: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/11.jpg)
Direct Semantics
![Page 12: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/12.jpg)
The implementation of Inheritance Please think how you’d implement
inheritance
Odds are you’re thinking of direct semantics
![Page 13: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/13.jpg)
ExtendedLanguage
class C2 extends C1 { void m2() {…}}
The idea Classes can be defined in new ways Since programs are not translated,
good old method lookup can’t work anymore
Language
class C1 { void m1() {…}}
We can computelookup(C, m)=…
For instance, lookup(C1, m1)=…
lookup(C2, m1)=???
![Page 14: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/14.jpg)
Extended method lookup
Needs to know what extends means
For instance, lookup(C3, m2) starts from C3
Don’t find m2, so proceeds with C2
And finds m2
class C1 { void m1() {…}}
class C2 extends C1 { void m2() {…}}
class C3 extends C2 { void m3() {…}}
![Page 15: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/15.jpg)
A comparison
Flattening DirectIntuitive YES Less than the
otherGood old method lookup
YES NO
Is efficient? NO YES
![Page 16: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/16.jpg)
Featherweight Jigsaw (FJig)
![Page 17: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/17.jpg)
Flexible class definitions class C ClassExpression ClassExpression ::=
BasicClass | merge ClassExpression1,
ClassExpression2| rename N to N’ in ClassExpression | hide N in ClassExpression | …others…
BasicClass ::= { …constr/fields/methods… }
![Page 18: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/18.jpg)
Basic class declaration One constructor; takes any kind of
parameters Internal representation hidden from clients
A series of members: fields and methods Members can be:
abstract virtual frozen local
no definition“someone” is expected
to provide it
there is a definition,but it can be later
replaced
there is a definition, that current clients will
see forever (even if replaced)
there is a definition, that no other object will
ever see
![Page 19: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/19.jpg)
FJig Nice per se More than that, can encode:
standard inheritance mixins traits … it’s a general framework for sw composition
Wouldn’t be wonderful to have an intuitive (flattening) semantics and a (rather complex but) efficient (direct) one?
Actually, no it wouldn’t … unless they’re equivalent! And they
are!
![Page 20: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/20.jpg)
An example class A {
abstract void m(); frozen int answer() { return 41; } local int loc() { return 1; }}
class B { frozen int answer() { return 42; } virtual void m() { loc(); } local int loc() { return answer(); } }
class C merge(rename answer to wrongAnswer in A),B
…what’s new C().answer()?
I’m “cheating” using an extra-sugared syntax primitive types and void
![Page 21: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/21.jpg)
Flattening steps (1 of 5) class C merge
(rename answer to wrongAnswer in A),B
class C merge(rename answer to wrongAnswer in{ abstract void m(); frozen int answer() { return 41; } local int loc() { return 1; }}), B
![Page 22: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/22.jpg)
Flattening steps (2 of 5) class C merge
(rename answer to wrongAnswer in{ abstract void m(); frozen int answer() { return 41; } local int loc() { return 1; }}), B
class C merge{ abstract void m(); frozen int wrongAnswer() { return 41; } local int loc() { return 1; }} , B
![Page 23: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/23.jpg)
Flattening steps (3 of 5) class C merge
{ abstract void m(); frozen int wrongAnswer() { return 41; } local int loc() { return 1; }} , B
class C merge{ abstract void m(); frozen int wrongAnswer()
{ return 41; } local int loc() { return 1; }} , { frozen int answer() { return
42; } virtual void m() { loc(); } local int loc() { return
answer(); } }
![Page 24: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/24.jpg)
Flattening steps (4 of 5) class C merge
{ abstract void m(); frozen int wrongAnswer()
{ return 41; } local int loc() { return 1; }} , { frozen int answer() { return
42; } virtual void m() { loc’(); } local int loc’() { return
answer(); } }
![Page 25: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/25.jpg)
Flattening steps (5 of 5) class C { // equivalent flattened
definition frozen int wrongAnswer() { return
41; } local int loc() { return 1; } frozen int answer() { return 42; } virtual void m() { loc’(); } local int loc’() { return answer(); }
} now we can easily see what new
C().answer() is and, quite obviously , it’s 42
![Page 26: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/26.jpg)
Direct Semanticsclass A {
abstract void m(); frozen int answer() {return 41; } local int loc() { return 1; }}
class C merge(rename answer to wrongAnswer in A),B
again, what does new C().answer() means? what is lookup(C, answer)?
class B { frozen int answer() {
return 42; } virtual void m() { loc(); } local int loc() { return answer(); } }
![Page 27: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/27.jpg)
Direct Semanticsclass A {
abstract void m(); frozen int answer() { return 41; } local int loc() { return 1; }}
class C merge(rename answer to wrongAnswer in A), B
class B { frozen int answer() { return 42;} virtual void m() { loc(); } local int loc() { return answer(); } }
lookup(C, answer) = lookup(merge …, answer) =
= lookup((rename…), answer)
and non-deterministically = lookup(B, answer)
![Page 28: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/28.jpg)
Lookup on a rename expression
lookup(rename FromN to ToN in ClassExpression, N)= failure if N=FromN lookup(ClassExpression, FromN) if N=ToN lookup(ClassExpression, N) otherwise
In the example: lookup((rename answer to wrongAnswer in A), answer)
fails, solookup(C, answer) = … 2 choices … = lookup(B, answer)
![Page 29: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/29.jpg)
Lookup on a namelookup(B, answer) = lookup(ClassExpression,
answer)
where ClassExpression is the class expression of B,
which is a base (flatten) class. So, we can conclude.
Believe it or not, I’ve just scratched the surface: direct semantics is no picnic
![Page 30: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/30.jpg)
Conclusions and further work
Flatten semantics: easy, intuitive but “performs” poorly
Direct semantics can be (rather) complex but it’s a good choice for implementation
FJig: general language for software composition encompasses inheritance, mixin, traits….
Given both semantics and proved equivalent Implemented interpreter as master-thesis:
http://www.disi.unige.it/person/LagorioG/FJig/ Exploring the equivalence for feature requiring
static types (e.g. overloading and static binding) Investigating smart implementation techniques
![Page 31: Plan of the talk](https://reader031.vdocuments.site/reader031/viewer/2022013012/56816688550346895dda3a62/html5/thumbnails/31.jpg)
Thank you