-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathreading.bib
176 lines (159 loc) · 7.05 KB
/
reading.bib
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
% This is the list of papers I'm interested in/trying to read/...
comments on \cite{simonyi95techrep}
* The author is well-known guy who developed initial versions of
Microsoft Word and Excel. (according to several people including
Gregor.)
@InProceedings{kienzle2002ecoop,
author = {J{\"o}rg Kienzle and Rachid Guerraoui},
title = {{AOP}: Does It Make Sense? The Case of Concurrency and Failures},
crossref = {ecoop2002},
key = {Aspect-oriented programming, abstraction, objects, concurrency, failures, exceptions, transactions},
pages = {37--61},
annote = {printed jul 2002; general interests},
abstract = {Concurrency and failures are fundamental problems in
distributed computing. One likes to think that the mechanisms
needed to address these problems can be separated from the
rest of the distributed application: in modern words, these
mechanisms could be aspectized. Does this however make sense?
This paper relates an experience that conveys our initial and
indeed biased intuition that the answer is in general
no. Except for simple academic examples, it is hard and even
potentially dangerous to separate concurrency control and
failure management from the actual application.
We point out the very facts that (1) an aspect-oriented
language can, pretty much like a macro language, be beneficial
for code factorization (but should be reserved to experienced
programmers), and (2) concurrency and failures are
particularly hard to aspectize because they are usually part
of the phenomenon that objects should simulate. They are in
this sense different than other concerns, like for instance
tracing, which might be easier to aspectize. }
}
@InProceedings{meseguer2002ecoop,
author = {Jose Meseguer and Carolyn Talcott},
title = {Semantic Models for Distributed Object Reflection},
crossref = {ecoop2002},
pages = {1--36},
note = {invited talk},
annote = {printed jul 2002; general interests},
abstract= {A generic formal model of distributed object reflection
is proposed, that combines logical reflection with a
structuring of distributed objects as nested configurations
of metaobject that can control subobjects under them. The
model provides mathematical models for a good number of
existing models of distributed reflection and of reflective
middleware. To illustrate the ideas, we show in some detail
how two important models of distributed actor reflection can
be naturally obtained as special cases of our generic model,
and discuss how several recent models of reflective
middleware can be likewise formalized as instances of our
model. }
}
@InProceedings{zenger2002ecoop,
author = {Matthias Zenger},
title = {Type-Safe Prototype-Based Component Evolution},
crossref = {ecoop2002},
pages = {470--??},
annote = {printed jul 2002; general interests},
abstract = {Component-based programming is currently carried out
using mainstream object-oriented languages. These languages
have to be used in a highly disciplined way to guarantee
flexible component composition and extensibility. This paper
investigates abstractions for component-oriented programming
on the programming language level. We propose a simple
prototype-based model for first-class components on top of a
class-based object-oriented language. The model is formalized
as an extension of Featherweight Java. Our calculus includes a
minimal set of primitives to dynamically build, extend, and
compose software components, while supporting features like
explicit context dependencies, late composition, unanticipated
component extensibility, and strong encapsulation. We present
a type system for our calculus that ensures type-safe
component definition, composition, and evolution. }
}
@InProceedings{aldrich2002ecoop,
author = {Jonathan Aldrich and Craig Chambers and David Notkin},
title = {Architectural Reasoning in ArchJava},
crossref = {ecoop2002},
pages = {334--367},
annote = {printed jul 2002; general interests},
abstract = {Software architecture describes the structure of a
system, enabling more effective design, program understanding,
and formal analysis. However, existing approaches decouple
implementation code from architecture, allowing
inconsistencies that cause confusion, violate architectural
properties, and inhibit software evolution. We are developing
ArchJava, an extension to Java that seamlessly unifies
software architecture with an object-oriented
implementation. In this paper, we show how ArchJava's type
system ensures that implementation code conforms to
architectural constraints. A case study applying ArchJava to
an Islamic tile design application demonstrates that ArchJava
can express dynamically changing architectures effectively
within implementation code, and suggests that the resulting
program may be easier to understand and evolve. },
serialNo = "18-8"
}
@InProceedings{benton2002ecoop,
author = {Nick Benton and Luca Cardelli and Cedric Fournet},
title = {Modern Concurrency Abstractions for {C\#}},
crossref = {ecoop2002},
pages = {415--440},
annote = {printed jul 2002; general interests},
abstract = {Polyphonic C is an extension of the C language with new
asynchronous concurrency constructs, based on the join
calculus. We describe the design and implementation of the
language and give examples of its use in addressing a range
of concurrent programming problems. }
}
@InProceedings{lawallXX,
author = {Julia L. Lawall},
title = {Faster Fourier Transforms via Automatic Program Specialization},
booktitle = {.},
year = {.},
OPTeditor = {},
OPTvolume = {},
OPTnumber = {},
OPTseries = {},
OPTaddress = {},
OPTmonth = {},
OPTorganization = {},
OPTpublisher = {},
OPTnote = {},
OPTannote = {printed sep 2002;
Maruyama implemented this on top of BCS}
}
@InProceedings{glew2002ecoop,
author = {Neal Glew and Jens Palsberg},
title = {Type-Safe Method Inlining},
crossref = {ecoop2002},
pages = {525--544},
annote = {printed jul 2002;
general interests; something to do with around/proceed}
}
@InProceedings{arnold2002ecoop,
author = {Matthew Arnold and Barbara G. Ryder},
title = {Thin Guards: A Simple and Effective Technique for Reducing the Penalty of Dynamic Class Loading},
crossref = {ecoop2002},
pages = {498--524},
annote = {printed jul 2002;
general interests},
serialNo = "17-14"
}
@InProceedings{ancona2002ecoop,
author = {Davide Ancona and Giovanni Lagorio and Elena Zucca},
title = {A Formal Framework for {Java} Separate Compilation},
crossref = {ecoop2002},
pages = {609--635},
annote = {something to do with AspectJ's separate compilation; half read, but not so exciting.}
}
@InProceedings{walker2000fse,
author = {Robert J. Walker and Gail C. Murphy},
title = {Implicit Context: Easing Software Evolution and Reuse},
booktitle = {SIGSOFT 2000 (FSE-8)},
pages = {69--78},
year = 2000,
address = {San Diego CA},
month = nov,
annote = {roughly read; wanted to know how he ment his execution history based pointcuts}
}