Christophe Courbage

Henri Loubergé

Béatrice Rey

On the properties of non-monetary measures for risks

Keywords: risk apportionment, superadditivity, RA-n utility premium risk apportionment, superadditivity, RA-n utility premium JEL classification: D81

This paper investigates how welfare losses for facing risks change as the risk environment of the decision-maker is altered. To that aim, we define the risk apportionment of order n (RA-n) utility premium as a measure of pain associated with facing the passage from one risk to a riskier one. Changes in risks are expressed through the concept of stochastic dominance of order n. Three configurations of risk exposures are considered. The paper first shows how the RA-n utility premium is modified when initial wealth becomes riskier. Second, the paper provides conditions on individual preferences for superadditivity of the RA-n utility premium. Third, the paper investigates welfare changes of merging increases in risks. These results offer new interpretations of the sign of higher derivatives of the utility function.

INTRODUCTION

The issue of how the presence of multiple risks modify individual behaviour in the face of another risk has been leading to a prolific literature during the last decades. 5 Most of these studies use monetary measures to analyze behaviour towards risk, the most wellknown being the risk premium and the willingness to pay. More recently, a few papers have used non-monetary measures to provide new behavioural results in the face of risks. In particular, the concept of utility premium originally introduced by [START_REF] Friedman | The utility analysis of choices involving risk[END_REF] has regained interest. For instance, [START_REF] Eeckhoudt | Putting risk in its proper place[END_REF] rely on the utility premium to propose a unified approach to explain the meaning of the signs of the successive derivatives of the utility function. Eeckhoudt and Schlesinger (2009) also reexamine the properties of the utility premium and explain the relevance of this tool for decision making. Recently, [START_REF] Crainich | On the intensity of downside risk aversion[END_REF] and [START_REF] Courbage | On non monetary measures in the face of risks and the signs of the derivatives[END_REF] used non-monetary measures of prudence and temperance to extract behavioural results. Such non-monetary measures not only offer alternative tools to analyse the individual loss of welfare due to the presence of risks, but also allow for much simpler conditions on individual preferences to predict behaviour towards risks.

An issue of importance when dealing with measures of risks is how these measures react to a riskier environment. In particular, knowing how welfare losses of facing increases in risks change as a function of the number of risk exposures offers crucial knowledge on how individuals react to riskier environment. To address these issues, this paper defines the risk apportionment of order n (RA-n) utility premium as a measure of pain associated with facing the passage from one risk to a worse one. Changes in risks are expressed through the specific concept of stochastic dominance of order n.

The paper first shows how the RA-n utility premium is modified when individual wealth becomes riskier. It makes it possible to generalise earlier results on the topic, and in particular those of [START_REF] Courbage | On non monetary measures in the face of risks and the signs of the derivatives[END_REF]. Second, the paper provides conditions on individual preferences for superadditivity and subadditivity of the RA-n utility premium. A measure is said to be superadditive or convex in the number of risks if the measured value of two risks is superior to the sum of the values of each risk; the opposite holding for subadditivity. Superadditivity/subadditivity sheds light on whether risks are self-aggravating for individuals. For instance, [START_REF] Eeckhoudt | Which shape for the cost curve of risk?[END_REF] show that risk vulnerability (see [START_REF] Gollier | Risk vulnerability and the tempering effect of background risk[END_REF] is a sufficient condition for superadditivity of the risk premium. The concept of subadditivity of risks measures has also been popularised through the definition of coherent risk measures defined by [START_REF] Artzner | Coherent risk measures[END_REF]. Third, the paper uses the RA-n utility premium to investigate a related but different issue, i.e. whether welfare loss changes when increases in risks are merged instead of facing them separately. This makes it possible to extend the recent results of [START_REF] Ebert | Greater mutual aggravation[END_REF] on mutual aggravation of risk changes in terms of mutual improvements of risk changes.

The paper shows that the degree of pain due to facing an increased risk grows when the initial wealth becomes riskier if the signs of the successive derivatives of the utility function alternate in signs, i.e. when preferences exhibit mixed risk-aversion as defined by [START_REF] Caballé | Mixed risk aversion[END_REF]. It also shows that mixed risk aversion of order 4 is sufficient for superadditivity of the RA-n utility premium. Finally, mixed risk-aversion is also shown to drive welfare changes of merging increases in risks. The results of this paper therefore provide new interpretations of the sign of higher derivatives of the utility function.

The paper is organised as follows. Section 2 introduces the benchmark model for non-monetary measures of risk and in particular the RA-n utility premium. Section 3 investigates the effect of riskier initial wealth on the RA-n utility premium. Section 4 addresses the conditions on individuals preferences for superadditivity/subadditivity of non-monetary measures of risks. Section 5 deals with welfare changes of merging increases in risks and provides a link with the work of [START_REF] Ebert | Greater mutual aggravation[END_REF]. Section 6 finally offers a short conclusion.

THE BENCHMARK MODEL

Non-monetary measures in the face of risks

Non-monetary measures in the face of risks stem from the work of [START_REF] Friedman | The utility analysis of choices involving risk[END_REF] who used expected utility theory to define risk aversion and introduced two ways for its measure. The two measures reflect the subjective cost of risk for a risk averter.

Let an individual's final wealth be represented by x + ˜ where x (x > 0) denotes the initial wealth of the individual and ˜ is a zero-mean random variable6 . The first measure of risk aversion in the face of the risk ˜ at wealth level x is a monetary measure, the risk premium π(x, ˜ ), and is such that:

E[u(x + )] = u(x -π(x, ˜ )), (1)
where u denotes the individual's von Neumann-Morgenstern utility function (with u (x) ≥ 0 ∀x) and E denotes the expectation operator. π(x, ˜ ) is the amount of money that the agent is ready to pay to get rid of the zero-mean risk . π(x, ˜ ) ≥ 0 if and only if the individual is risk-averse (u (x) ≤ 0 ∀x).

The second one is a non-monetary measure of risk aversion, the utility premium, w A (x, ˜ ):

w A (x, ε) = u(x) -E[u(x + ε)]. (2)
w A (x, ε) measures the degree of "pain" associated with facing the risk ε, where pain is measured by the loss in expected utility from adding the risk ε to wealth x. From Jensen's inequality, w A (x) ≥ 0 if and only if u (x) ≤ 0 ∀x7 . Prudence is known as preference for a zero-mean risk in the wealthier state of nature. The prudence utility premium as introduced by [START_REF] Crainich | On the intensity of downside risk aversion[END_REF], denoted w P (x, ε), measures the increase in pain of facing the risk ε in the presence of a sure loss l > 0. This is defined as follows:

w P (x, ε) = u(x -l) -E[u(x -l + ε)] -(u(x) -E[u(x + ε)]), (3)
which is equivalent to:

w P (x, ε) = w A (x -l, ˜ ) -w A (x, ˜ ). ( 4
)
Naturally, w P (x, ε) ≥ 0 if and only if u ≥ 08 . Temperance is known as preference for disaggregation of two independent zero-mean risks. The temperance utility premium as introduced by Courbage and Rey (2010), denoted w T (x, ε), measures the increase in pain of facing the risk ε in the presence of an independent zero-mean risk θ. It writes as follows:

w T (x, ε) = E[u(x + θ)] -E[u(x + θ + ε)] -(u(x) -E[u(x + ε)]), (5)
which is equivalent to:

w T (x, ε) = w A (x + θ, ˜ ) -w A (x, ˜ ), (6)
w T (x, ε) ≥ 0 if and only if u (4) ≤ 09 . [START_REF] Courbage | On non monetary measures in the face of risks and the signs of the derivatives[END_REF] suggested an extension of these measures to higher orders defining the utility premium by iteration following [START_REF] Eeckhoudt | Putting risk in its proper place[END_REF]. Denoting w (2) (x, ε) the [START_REF] Friedman | The utility analysis of choices involving risk[END_REF] utility premium of Eq. (2), we can proceed from their remark by defining for all n even and n ≥ 2:

w (n+1) (x, ˜ ) = w (n) (x -l, ˜ ) -w (n) (x, ˜ ) with l > 0 and w (n+2) (x, ˜ ) = w (n) (x + θn , ˜ ) -w (n) (x, ˜ ),
where θn is an independent random variable (i.e. random variables ˜ , θ2 , θ4 , θ6 , etc, are mutually independent) and such that E( θn ) = 0. As an illustration, when n = 2, w (n+1) (x, ˜ ) corresponds to the prudence utility premium, w P (x, ˜ ), and w (n+2) (x, ˜ ) corresponds to the temperance utility premium, w T (x, ˜ ), as defined by equations ( 4) and (6).

The RA-n utility premium

While [START_REF] Courbage | On non monetary measures in the face of risks and the signs of the derivatives[END_REF] suggested to define utility premia of higher orders by iteration of the previous premia of lower orders and in the context of specific lotteries, in this section we present a very general way to define the utility premium at higher orders using the concept of stochastic dominance of order n.

Let's consider two risky situations: a first situation represented by the random variable Y 1 and a second one represented by the random variable X 1 . We assume that X 1 and Y 1 are independent, and that Y 1 dominates X 1 via nth-order stochastic dominance (X 1 n-SD Y 1 ).

The concept of nth-order stochastic dominance is defined as follows10 . Consider Y 1 and X 1 with F and G, respectively, their two cumulative distribution functions of wealth, defined over a probability support contained within the interval [a, b].

Define F 1 = F and G 1 = G. Now define F k+1 (z) = z a F k (t)dt and G k+1 (z) = z a G k (t)dt for k ≥ 1. The variable Y 1 dominates X 1 via nth-order stochastic dominance (X 1 n-SD Y 1 ) if F n (z) ≤ G n (z) for all z, and if F k (b) ≤ G k (b) for k = 1, 2, .., n.
When the n -1 moments of X 1 and Y 1 are equals, nth-order stochastic dominance coincides with the [START_REF] Ekern | Increasing Nth degree risk[END_REF] concept of increase in nth-order risk (X 1 n Y 1 ). [START_REF] Ekern | Increasing Nth degree risk[END_REF] definition includes the case of mean-preserving increase in risk of Rothshild and Stiglitz (1970) as well as of increase in downside risk defined by [START_REF] Menezes | Increasing downside risk[END_REF] as, respectively, a second-degree and a third-degree increase in risk.

Our objective is to define the non-monetary measure of the cost of facing the risk transition e.g. the passage from Y 1 to X 1 (with X 1 n-SD Y 1 ). Let's define the function w as follows11 :

w(x; Y 1 , X 1 ) = E[u(x + Y 1 )] -E[u(x + X 1 )]. (7)
The function w(x; Y 1 , X 1 ) measures the degree of pain associated with facing the passage from the risk Y 1 to the less favorable one, X 1 , when the decision-maker's initial wealth is x. We formulate the following definition.

Definition. Given two independent risks, Y 1 and X 1 such that Y 1 dominates X 1 via nth-order stochastic dominance (X 1 n-SD Y 1 ), the function w defined as w(

x; Y 1 , X 1 ) = E[u(x+Y 1 )]-E[u(x+X 1 )
] is named the "risk apportionment of order n utility premium", also denoted the RA-n utility premium. It measures the degree of pain due to the aggravating nth-order stochastic dominance risk.

From [START_REF] Ingersoll | Theory of Financial Decision Making[END_REF], we observe that w(x; Y 1 , X 1 ) ≥ 0 if and only if (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n. Note that (-1) (1+n) u (n) ≥ 0 ∀n ≥ 1 means that all odd derivatives of u are positive and all even derivatives of u are negative. Following [START_REF] Brockett | A class of utility functions containing all the common utility functions[END_REF] and according to [START_REF] Caballé | Mixed risk aversion[END_REF], an individual with such a utility function is said to be mixed risk-averse. Hence, for all order n, the RA-n utility premium of a mixed risk averse agent is always positive. In other words, such an individual always incurs a pain when facing the passage from the risk Y 1 to a less favorable one X 1 dominated via nth-order stochastic dominance. We will label a utility function u as mixed risk-averse of order n if it verifies (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n.

Particular cases of the RA-n utility premium are the various premia defined in the previous section for which Y 1 dominates X 1 via nth-order Ekern's dominance (X 1 n Y 1 ). Indeed, following following [START_REF] Ekern | Increasing Nth degree risk[END_REF]

, if X 1 n Y 1 then w(x; Y 1 , X 1 ) ≥ 0 if and only if (-1) (1+n) u (n) ≥ 0. For instance, when Y 1 = 0 and X 1 is a zero-mean background risk, X 1 = ˜ with E(˜ ) = 0, the function w writes as w(x; 0, ˜ ) = u(x) -E[u(x + ˜ )] = w A (x, ε).
It is the utility premium introduced by [START_REF] Friedman | The utility analysis of choices involving risk[END_REF] to define the nonmonetary risk aversion measure: w(x; 0, ˜ ) ≥ 0 if and only if the individual is risk-averse (u ≤ 0). When Y 1 and X 1 are defined as equiprobable lotteries describing an increase in downside risk [START_REF] Menezes | Increasing downside risk[END_REF]):

Y 1 = [-l, ˜ ; 1 2 , 1 2 ] and X 1 = [0, -l + ˜ ; 1 2 , 1 2
] with l > 0 and E(˜ ) = 0, the function w writes as

w(x; Y 1 , X 1 ) = 1 2 w P (x, ˜ ), (8)
where w P (x, ˜ ) is the prudence utility premium defined by [START_REF] Crainich | On the intensity of downside risk aversion[END_REF] which is positive if and only if u (3) ≥ 0. When Y 1 and X 1 are defined as the following lotteries:

Y 1 = [ θ, ˜ ; 1 2 , 1 2 ] and X 1 = [0, θ + ˜ ; 1 2 , 1 2 ]
, with θ and ˜ independent and zero mean random variables (E( θ) = E(˜ ) = 0), the function w writes as

w(x; Y 1 , X 1 ) = 1 2 w T (x, ˜ ), (9)
where

w T (x, ˜ ) = E[u(x + θ)] + E[u(x + ˜ )] -u(x) -E[u(x + θ + ˜ )
] corresponds to the temperance utility premium defined by [START_REF] Courbage | On non monetary measures in the face of risks and the signs of the derivatives[END_REF] which is positive if and only if u (4) ≤ 0.

RA-n UTILITY PREMIUM AND CHANGES IN RISKS

As Courbage and Rey (2010), we can investigate, in the more general context of the RA-n utility premium, how this measure reacts to the introduction on wealth of a sure loss (-l with l > 0) or a zero-mean background risk (˜ with E(˜ ) = 0). As intuition suggests, the pain increases in both cases under usual conditions on the signs of higherorders derivatives of the utility function. Indeed, considering the impact of a sure loss and a background risk on the RA-n utility premium, we obtain:

w(x -l; Y 1 , X 1 ) -w(x; Y 1 , X 1 ) ≥ 0 ⇔ (-1) (k+1) u (k) ≥ 0 ∀k = 1, . . . , n + 1, ( 10
) w(x + ˜ ; Y 1 , X 1 ) -w(x; Y 1 , X 1 ) ≥ 0 ⇔ (-1) (k+1) u (k) ≥ 0 ∀k = 1, . . . , n + 2. ( 11
)
These results are rather easy to obtain. Eq. ( 10) rewrites as Eeckhoudt et al. (2009), we obtain that this inequality holds iff (-1) (k+1) u (k) ≥ 0 ∀k = 1, . . . , n + 1. In the same vein, Eq. ( 11) rewrites as

E[u(x + Y 1 )] -E[u(x + X 1 )] ≤ E[u(x -l + Y 1 )] -E[u(x -l + X 1 )] which is equivalent to E[u(x + Y 1 )] + E[u(x -l + X 1 )] ≤ E[u(x + X 1 )] + E[u(x -l + Y 1 )]. Using Theorem 3 of
E[u(x + Y 1 )] -E[u(x + X 1 )] ≤ E[u(x + ˜ + Y 1 )] -E[u(x + ˜ + X 1 )] which is equivalent to E[u(x + Y 1 )] + E[u(x + ˜ + X 1 )] ≤ E[u(x + X 1 )] + E[u(x + ˜ + Y 1 )].
Using Eeckhoudt et al. (2009), we obtain that this inequality holds iff (-1) (k+1) u (k) ≥ 0 ∀k = 1, . . . , n + 2.

Eqs. ( 10) and ( 11) have intuitive explanations. If we consider a decision-maker with a mixed risk-averse utility function of order n + 2, Eqs. ( 10) and ( 11) respectively mean that the RA-N utility premium (∀N ≤ n + 1) is vulnerable to a sure loss, and that the RA-N utility premium (∀N ≤ n) is vulnerable to a zero-mean background risk.

Such analysis can be extended to a more general context by investigating the degree of pain associated with facing the passage from Y 1 to X 1 when the wealth level becomes riskier. A riskier wealth corresponds to the random wealth level, initially equal to x + Y 2 , becoming x+X 2 where Y 2 dominates X 2 via sth-order stochastic dominance (X 2 s-SD Y 2 with X 2 and Y 2 being independent random variables). The degree of pain associated with facing the passage from Y 1 to X 1 when the wealth level becomes riskier is defined by the following expression12 :

w(x + X 2 ; Y 1 , X 1 ) -w(x + Y 2 ; Y 1 , X 1 ). ( 12
)
A positive sign of ( 12) means that the pain facing the passage from Y 1 to X 1 increases when the wealth level becomes riskier. We obtain the following proposition.

Proposition 1. Consider mutually independent random variables X 1 , Y 1 , X 2 , and Y 2 , such that X 1 n-SD Y 1 and X 2 s-SD Y 2 . Then w(x + X 2 ; Y 1 , X 1 ) -w(x + Y 2 ; Y 1 , X 1 ) ≥ 0 for all utility functions u such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n + s.

Proof. Using the definition of w, w(x + X Eeckhoudt et al. (2009), this last expression is equivalent to (-1) (1+k) u (k) ≥ 0 for k = 1, . . . , n + s.

2 ; Y 1 , X 1 ) -w(x + Y 2 ; Y 1 , X 1 ) ≥ 0 rewrites equivalently as E[u(x+Y 1 +X 2 )]-E[u(x+X 1 +X 2 )] ≥ E[u(x+Y 1 +Y 2 )]-E[u(x+X 1 +Y 2 )], that is equivalent to E[u(x + Y 1 + X 2 )] + E[u(x + X 1 + Y 2 )] ≥ E[u(x + Y 1 + Y 2 )] + E[u(x + X 1 + X 2 )]. Following
Proposition 1 can be interpreted in a similar way as Eqs. ( 10) and ( 11). If we consider a decision-maker with a mixed risk-averse utility function of order n + s, Proposition 1 means that the RA-N utility premium (∀N ≤ n-s) is vulnerable to a detrimental change of order s in the background risk.

In order to provide a different interpretation of the results, we restrict our attention on the special case of Ekern dominance as often done in the literature. The advantage of this dominance rule is that the positive sign of the RA-n utility premium depends only on the sign of the nth derivative of u. Indeed, according to [START_REF] Ekern | Increasing Nth degree risk[END_REF], w(x; Y 1 , X 1 ) ≥ 0 if and only if (-1) (1+n) u (n) ≥ 0, i.e. risk apportionment of order n holds. From Proposition 1, we can extrapolate the following corollary.

Corollary 1. The four following items are equivalent:

(1) risk apportionment of order n holds, (2) the pain due to misaportionment of order (n -1) is vulnerable to a sure loss, (3) the pain due to misaportionment of order (n -2) is vulnerable to a zero-mean background risk, (4) the pain due to misaportionment of order (n -s) is vulnerable to an increase in risk of order s.

Note that item (2) also means that the RA-n-1 utility premium is decreasing in the wealth level x and item (3) means that the RA-n-2 utility premium is convex in x. This is rather intuitive as when the individual gets richer the pain of facing increases in risks is reduced as he can deal with them more easily, but this reduction in pain diminishes as the individual's wealth increases.

Corollary 1 offers an alternative interpretation of the sign of the utility function norder derivative (u (n) ) which can be easily understood and remembered, without reference to any specific decision problem. For instance in the case of the utility premium for which Y 1 = 0 and X 1 = ˜ ( X1 2 Y 1 ), Corollary 1 tells us that the degree of pain of facing the risk ˜ increases when initial wealth becomes risky (i.e. when any zero-mean risk X 2 is added to initial wealth) for a temperant individual. In the same way, in the case of the prudence premium, for which X 1 represents an increase in downside risk over Y 1 ( X1 3 Y 1 ), Corollary 1 tells us that the degree of pain of facing an increase in downside risk increases when initial wealth becomes risky for an individual featuring edginess13 .

SUPERADDITIVITY OF THE RA-n UTILITY PREMIUM

An issue of importance when dealing with measures of risks is that of superadditivity or subadditivity of these measures. From the risk theory literature (see for example [START_REF] Buhlmann | Premium calculation from top down[END_REF] or [START_REF] Gerber | On the representation of additive principles of premium calculation[END_REF]), it is well-known that financial risks are very often self-aggravating. This would suggest that the cost of risk for two independent risks should be greater than the sum of costs of the two risks taken in isolation. If it were the case, the cost of risk would be superadditive. [START_REF] Eeckhoudt | Which shape for the cost curve of risk?[END_REF] examine this issue when the cost of risk is defined in terms of risk premium. They show that the risk premium is superadditive if risk aversion is risk vulnerable14 .

We first address the issue of superadditivity when the cost of risk is defined in nonmonetary terms through the concept of the Friedman-Savage utility premium. The definition of superadditivity is the following. A real-valued function f is superadditive if f (n 1 + n 2 ) is larger than f (n 1 ) + f (n 2 ) for all n 1 > 0 and n 2 > 0. The opposite inequality holding true for subadditivity. We show that the Friedman-Savage utility premium is superadditive for all temperant decision-makers. This gives the following proposition.

Proposition 2. Consider mutually independent zero-mean risks X 1 and X 2 . Then the Friedman-Savage utility premium is superadditive (i.e. w(x; 0, X 1 + X 2 ) ≥ w(x; 0, X 1 ) + w(x; 0, X 2 )) for all utility functions u such that u (4) ≤ 0.

Proof. Superadditivity of the Friedman-Savage utility premium rewrites as u(x) - Eeckhoudt et al. (2009), this inequality is equivalent to w T ≥ 0, i.e. u (4) ≤ 0 since the introduction of a zero-mean risk X i (i = 1, 2) is an increase in risk of order 2 in the sense of Ekern.

E[u(x + X 1 + X 2 )] ≥ u(x) -E[u(x + X 1 )] + u(x) -E[u(x + X 2 )]. Using
Proposition 2 states that the pain of facing two risks simultaneously is higher than the sum of the pains of facing each risk separately for a temperant individual. Let's make two remarks. First, while risk vulnerability is required for monetary measures of risk to be superadditive, for which temperance is only a necessary condition, temperance here is sufficient to obtain superadditivity in the case of the Fiedman-Savage utility premium. Second, obviously the superadditivity of the Friedman-Savage utility premium holds for all "mixed risk-averse of order 4" decision-makers.

Extending superadditivity to the RA-n utility premium allows us to consider the more following general context. Instead of considering the passage from 0 to X i (i = 1, 2), we consider the passage from a risky situation Y to a less favorable one X i (i = 1, 2). The superadditivity to the RA-n utility premium writes as

w(x; Y, X 1 + X 2 ) ≥ w(x; Y, X 1 ) + w(x; Y, X 2 ), (13)
where Y , X 1 and X 2 are zero-mean mutually independent random variables. Subadditivity of the utility premium corresponds naturally to the opposite inequalities. We obtain the following result.

Proposition 3. Consider mutually independent zero-mean risks, X 1 , X 2 and Y . Then the RA-n utility premium is superadditive (i.e. w(x; Y, X 1 + X 2 ) ≥ w(x; Y, X 1 ) + w(x; Y, X 2 )) for all utility functions u such that u ≤ 0 and u (4) ≤ 0 .

Proof. w(x; Y, X 1 + X 2 ) ≥ w(x; Y, X 1 ) + w(x; Y, X 2 ) is equivalent to E[u(x + X 1 )] + E[u(x + X 2 )] ≥ E[u(x + X 1 + X 2 )] + E[u(x + Y )]. If u ≤ 0 then E[u(x + Y )] ≤ u(x) and then E[u(x + X 1 + X 2 )] + E[u(x + Y )] ≤ E[u(x + X 1 + X 2 )] + u(x). If u (4) ≤ 0 then E[u(x + X 1 + X 2 )] + u(x) ≤ E[u(x + X 1 )] + E[u(x + X 2 )] (Eeckhoudt et al. ( 2009
)). Consequently, if u ≤ 0 and u (4) ≤ 0 then E[u(x + X 1 + X 2 )] + E[u(x + Y )] ≤ E[u(x + X 1 )] + E[u(x + X 2 )].
According to Proposition 3, the pain of facing a change in two risks simultaneously is higher than the sum of the pains of facing two changes in risk separately for all risk-averse and temperant decision-makers. Obviously the result holds for all "mixed risk-averse of order 4" decision-makers. Note that Proposition 2 holds for all temperant decision makers i.e. for all u such that u (4) ≤ 0 whatever the sign of other lower order derivatives contrary to Proposition 3 that imposes risk aversion (u ≤ 0). Risk aversion is not required in the case of the Savage-Friedman utility premium because assuming Y = 0 implies that superadditivity rewrites equivalently as preference for harms disaggregation (Eeckhoudt et al. (2009)). In Proposition 3 (where Y is a zero-mean independent risk) it is no longer the case. Imposing risk aversion ensures that E[u(x + Y )] ≤ u(x), and then coupled with u (4) ≤ 0 is sufficient to obtain superadditivity. In the case of a risk lover,

E[u(x + Y )] ≥ u(x) and then the sum E[u(x + X 1 + X 2 )] + E[u(x + Y )] can be larger than the sum E[u(x + X 1 )] + E[u(x + X 2 )
]. Note that Proposition 3 holds whatever the nature of the change in risk between Y and respectively X 1 and X 2 . Indeed, for any stochastic dominance levels n and s such that X 1 n-SD Y and X 2 s-SD Y , Proposition 3 holds.

MERGING CHANGES IN RISKS

While the previous section analyzes superadditivity of the RA-n utility premium, this section addresses merging properties.

To do so, we consider a change in risk as the passage from Y 1 to X 1 and from Y 2 to X 2 with X 1 n-SD Y 1 and X 2 s-SD Y 2 where risks Y 1 , Y 2 , X 1 and X 2 are mutually independent and where Y 1 and Y 2 are zero-mean risks. We wonder under which conditions on the utility function u the non monetary cost of the total change in risk (passage from (Y 1 + Y 2 ) to (X 1 + X 2 )) is larger than the sum of the non-monetary cost of each change in risk (passage from Y 1 to X 1 and simultaneously passage from Y 2 to X 2 ). More formally, we wonder what properties of u ensure the following inequality:

w(x; Y 1 + Y 2 , X 1 + X 2 ) ≥ w(x; Y 1 , X 1 ) + w(x; Y 2 , X 2 ). ( 14
)
The following proposition provides conditions for such a comparison.

Proposition 4. Consider mutually independent random variables X 1 , X 2 , Y 1 and Y 2 , such that X 1 n-SD Y 1 , X 2 s-SD Y 2 , with E(Y 1 ) = E(Y 2 ) = 0. Then the RA-n utility premium verifies w(x; Y 1 + Y 2 , X 1 + X 2 ) ≥ w(x; Y 1 , X 1 ) + w(x; Y 2 , X 2 ) for all utility func- tions u such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n + s, ∀n ≥ 2, ∀s ≥ 2.
Proof. Since E(Y 1 ) = 0 we have Y 1 2 0. Given that X 2 s Y 2 and applying Eeckhoudt et al. (2009) theorem, we know that

E[u(x+Y 2 )]+E[u(x+X 2 +Y 1 )]-E[u(x+ X 2 )] -E[u(x + Y 1 + Y 2 )] ≤ 0 for all u such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , s + 2.
Analogously, since E(Y 2 ) = 0 we have Y 2 2 0. Given that X 1 n Y 1 and applying Eeckhoudt et al. (2009) theorem, we know that

E[u(x+Y 1 )]+E[u(x+X 1 +Y 2 )]-E[u(x+ X 1 )] -E[u(x + Y 1 + Y 2 )] ≤ 0 for all u such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n + 2. How- ever, Eeckhoudt et al. (2009) theorem gives E[u(x+Y 1 +Y 2 )]+E[u(x+X 1 +X 2 )]-E[u(x+ X 1 + Y 2 )] -E[u(x + Y 1 + X 2 )] ≤ 0 for all u such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n + s. Consequently, if u is such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n + s, ∀n ≥ 2, ∀s ≥ 2 then the following inequality holds: E[u(x + Y 2 )] + E[u(x + X 2 + Y 1 )] -E[u(x + X 2 )] -E[u(x + Y 1 +Y 2 )] + E[u(x+Y 1 )]+E[u(x+X 1 +Y 2 )]-E[u(x+X 1 )]-E[u(x+Y 1 +Y 2 )] + E[u(x+ Y 1 +Y 2 )]+E[u(x+X 1 +X 2 )]-E[u(x+X 1 +Y 2 )]-E[u(x+Y 1 +X 2 )] ≤ 0. It rewrites equiv- alently as: E[u(x + Y 1 )] -E[u(x + X 1 )] + E[u(x + Y 2 )] -E[u(x + X 2 )] ≤ E[u(x + Y 1 + Y 2 )] - E[u(x + X 1 + X 2 ) that is equivalent to w(x; Y 1 , X 1 ) + w(x; Y 2 , X 2 ) ≤ w(x; Y 1 + Y 2 , X 1 + X 2 ) that ends the proof.
Proposition 4 refers to a merging property. It means that welfare is reduced by merging changes in risks instead of facing them separately, i.e. the welfare loss of both increases in risks taken together is larger than the sum of welfare losses from assuming each increase in risk separately.

Note that when Y 1 = Y 2 = 0 (that implies considering n = s = 2) and E(X 1 ) = E(X 2 ) = 0, the superadditivity property of the Friedman-Savage utility premium coincides with this merging property. Indeed inequality ( 14) rewrites as w(x; 0, X 1 + X 2 ) ≥ w(x; 0, X 1 ) + w(x; 0, X 2 ) which is precisely the inequality describing the superadditivity of the Friedman-Savage utility premium in Proposition 2. Hence, superadditivity of the Friedman-Savage utility premium means that welfare is reduced by merging increases in risks instead of facing them separately. This result is reminiscent of [START_REF] Samuelson | Risk and uncertainty: A fallacy of large numbers[END_REF] who points out that riskaverters prefer to subdivide risks instead of facing them in one shot. Similarly, [START_REF] Eeckhoudt | The law of large (small?) numbers and the demand for insurance[END_REF] show that risk-averters reduce their demand for insurance with a positive loading when the total property at risk is scattered on smaller independent units.

In the context described by Proposition 4, the two risk sets (Y 1 , X 1 ) and (Y 2 , X 2 ) are considered in isolation. In Eq. ( 14), on the RHS, there is no link between (Y 1 , X 1 ) on one hand and (Y 2 , X 2 ) on the other hand. Nevertheless, these two risk sets are present in the DM's environment. A change of perspective arises if we take this fact into account, and if we consider that risk 2 is a background risk for the management of risk 1, and inversely. Interestingly, it turns out that this change of perspective reverses the result. For example, in the case of the Friedman-Savage utility premium, we obtain the following proposition.

Proposition 5. Given mutually independent zero-mean random variables, X 1 and X 2 , the Friedman-Savage utility premium verifies w(x; 0, X 1 + X 2 ) ≤ w(x + X 2 ; 0, X 1 ) + w(x + X 1 ; 0, X 2 ) for all utility functions u such that u (4) ≤ 0.

Proof. The inequality w(x; 0, X 1 + X 2 ) ≤ w(x + X 2 ; 0, X 1 ) + w(x + X 1 ; 0, X 2 ) rewrites as

E[u(x + X 2 )] -E[u(x + X 2 + X 1 )] + E[u(x + X 1 )] -E[u(x + X 1 + X 2 )] ≥ u(x) - E[u(x + X 1 + X 2 )], equivalent to E[u(x + X 2 )] + E[u(x + X 1 )] ≥ u(x) + E[u(x + X 1 + X 2 )].
Following Eeckhoudt et al. (2009) theorem, this inequality holds for all utility function u verifying u (4) ≤ 0.

Proposition 5 means that the welfare loss of facing the total increase in risk (passage from 0 to (X 1 + X 2 )) is smaller than the welfare loss of facing the first increase in risk (passage from 0 to X 1 ) when the second risk X 2 is considered as a background risk (i.e. a risk that impacts the wealth level x) plus the welfare loss of facing the second increase in risk (passage from 0 to X 2 ) when the first X 1 is considered as a background risk. The result can also be generalized, yielding the following proposition. Proposition 6. Consider mutually independent random variables X 1 , X 2 , Y 1 , and Y 2 such that X 1 n-SD Y 1 and X 2 s-SD Y 2 . Then the two following items (a) and (b) hold for all utility functions u such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n + s:

(a) w(x; Y 1 + Y 2 , X 1 + X 2 ) ≤ w(x + X 2 ; Y 1 , X 1 ) + w(x + X 1 ; Y 2 , X 2 ), (b) w(x; Y 1 + Y 2 , X 1 + X 2 ) ≥ w(x + Y 2 ; Y 1 , X 1 ) + w(x + Y 1 ; Y 2 , X 2 ).
Proof. Item (a) rewrites as: Eeckhoudt et al. (2009) theorem, this inequality holds for all u such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n + s. Item (b) rewrites as:

E[u(x + Y 1 + Y 2 )] -E[u(x + X 1 + X 2 )] ≤ E[u(x + X 2 + Y 1 )] -E[u(x + X 2 + X 1 )] + E[u(x + X 1 + Y 2 )] -E[u(x + X 1 + X 2 )] that is equivalent to E[u(x+Y 1 +Y 2 )]+E[u(x+X 1 +X 2 )] ≤ E[u(x+Y 2 +X 1 )]+E[u(x+Y 1 +X 2 )]. Following
E[u(x + Y 1 + Y 2 )] -E[u(x + X 1 + X 2 )] ≥ E[u(x + Y 2 + Y 1 )] -E[u(x + Y 2 + X 1 )] + E[u(x + Y 1 + Y 2 )] -E[u(x + Y 1 + X 2 )] that is equivalent to E[u(x+Y 1 +Y 2 )]+E[u(x+X 1 +X 2 )] ≤ E[u(x+Y 2 +X 1 )]+E[u(x+Y 1 +X 2 )]
i.e. the same inequality as the one of item (a).

Item (a) is the generalization of Proposition 5 (where Y 1 = Y 2 = 0, n = s = 2 and E(X 1 ) = E(X 2 ) = 0). But in this general case, background risks can also be Y 1 and Y 2 that provides item (b). Note also that in the case where Y 1 = Y 2 = 0, item (b) rewrites as w(x; 0, X 1 + X 2 ) ≥ w(x; 0, X 1 ) + w(x; 0, X 2 ) that is the result of Proposition 2.

The intuitive interpretation of Proposition 6 is the following. The difference between items (a) and (b) arises from background risk considerations on the RHS. In item (a), the background risks taken into account are the worse risks X 1 and X 2 while they are the better ones Y 1 and Y 2 in item (b). In item (a), the decision-maker is aware that risk Y 2 will be replaced by risk X 2 when she feels the loss of welfare from facing the risk X 1 instead of Y 1 . In item (b), the decision-maker is blind to this risk substitution. She feels a reduced loss from the sum of individual risk substitutions because she ignores that risk Y 2 will be replaced by risk X 2 when dealing with risk 1, and she ignores that risk Y 1 will be replaced by risk X 1 when dealing with risk 2. In this sense, item (a) reflects a kind of rational expectations, whereas item (b) reflects blindness.

It should also be stressed that following [START_REF] Ebert | Greater mutual aggravation[END_REF], item (b) of Proposition 6 can have another interpretation in terms of mutual aggravation of risks changes. Using the perspective of these authors, we show that item (a) can also be interpreted in terms of mutual improvement of risks changes.

To reach such conclusion, we have to consider the following property of the RA-n utility premium that stands from the fact that risks are additive: Property 1. Given mutually independent random variables, X 1 , Y 1 and Z. Then

w(x + Z; Y 1 , X 1 ) = w(x; Y 1 + Z, X 1 + Z).
The proof is straightforward. By definition of the RA-n utility premium, we have:

w(x + Z; Y 1 , X 1 ) = E[u(x + Z + Y 1 )] -E[u(x + Z + X 1 )] = w(x; Y 1 + Z, X 1 + Z).
Using this property, Proposition 6 can be rewritten as follows.

Corollary 2. Consider mutually independent random variables X 1 , X 2 , Y 1 , and Y 2 such that X 1 n-SD Y 1 and X 2 s-SD Y 2 . Then the two following items (a) and (b) hold for all utility functions u such that (-1) (1+k) u (k) ≥ 0 ∀k = 1, . . . , n + s:

(a) w(

x; Y 1 + Y 2 , X 1 + X 2 ) ≤ w(x; X 2 + Y 1 , X 2 + X 1 ) + w(x; X 1 + Y 2 , X 1 + X 2 ), (b) w(x; Y 1 + Y 2 , X 1 + X 2 ) ≥ w(x; Y 2 + Y 1 , Y 2 + X 1 ) + w(x; Y 1 + Y 2 , Y 1 + X 2 ).
Item (b) of Corollary 2 is identical to Eq. ( 1) of [START_REF] Ebert | Greater mutual aggravation[END_REF] 15 , which according to these authors means that the utility from avoiding both risk changes at once is larger than the utility from avoiding the first risk change plus the utility from avoiding the second risk change. In other words, [START_REF] Ebert | Greater mutual aggravation[END_REF] reinterpret preferences for combining good with bad given by Eeckhoudt et al. (2009) to explain the alternance of signs of successive derivatives as mutual aggravation of risk changes, i.e. the decision-maker's trait of perceiving two risks changes as mutually aggravating.

Following [START_REF] Ebert | Greater mutual aggravation[END_REF], we can provide a new interpretation of item (a) of Corollary 2 in terms of mutual improvement as follows: the increase in utility due to the two improvements at once (passage from (X 1 + X 2 ) to (Y 1 + Y 2 )) is smaller than the increase in utility due to the improvement of the first risk plus the increase in utility due to the improvement of the second risk. This provides a new interpretation of preferences for combining good with bad as mutual improvement of risk changes, i.e. the decision-maker's trait of perceiving two risks changes as mutually improving.

CONCLUSION

The paper provides a generalization of non-monetary measures of risk by introducing the concept of risk apportionment of order n (RA-n) utility premium. This measure reflects the degree of pain due to facing the transition from one risk to a more severe one. Changes in risks are expressed through the concept of stochastic dominance of order n. Risk apportionment is taken as a starting point using the definitions of attitudes towards risk introduced by [START_REF] Eeckhoudt | Putting risk in its proper place[END_REF]. The prudence utility premium and the temperance utility premium are special cases of our RA-n utility premium.

We first show that the RA-n utility premium increases when the decision-maker faces a riskier wealth under mixed risk aversion. We then turn to the issue of deciding whether the RA-n utility premium is subadditive or superadditive, i.e., deciding whether the cost of an increase in several risks faced jointly is smaller or larger than the sum of these increases in risks faced independently. We obtain that the Friedman-Savage utility premium for an individual with no initial risk is superadditive if the fourth derivative of the utility function is negative (the decision-maker is temperant). We further show that the more general RA-n utility premium is superadditive if the decision-maker is mixed risk averse of order 4. We finally address a related but different issue which is whether it is valuable to merge risks instead of facing them in separate entities. Our results show that an individual whose preferences are mixed-risk averse will feel more pain from merging increases in risk than from facing them in separate entities. However, the result is reversed if risks in separate entities are considered as background risks of each other, and if the individual is aware that both risks will deteriorate. Links with the concept of mutual aggravation of risks introduced by [START_REF] Ebert | Greater mutual aggravation[END_REF] are also provided.

The results in this paper provide new interpretations of the sign of higher derivatives of the utility function. As all commonly used utility functions in economic theory, with the first derivative being positive and the second one being negative, exhibit mixed risk aversion, our results then apply to most individuals facing a deterioration in their risk environment.

See Eeckhoudt and Gollier (2013) for a review.

We assume that the support of ˜ is defined such that x + is in the domain of u.

We assume throughout this article that the utility function u is nth differentiable. As it is usual, we assume that the derivative of order k (∀k ≥ 1), denoted u (k) (x), has a constant sign in the domain of u: u (k) (x) ≥ 0 or u (k) (x) ≤ 0 ∀x. To simplify notations we will only write u (k) ≥ 0 or u (k) ≤ 0.

To see this note that, using[START_REF] Eeckhoudt | Putting risk in its proper place[END_REF], Eq. (3) is positive by preference for disaggregation of harms by a prudent individual. Now, prudence defined in this way is equivalent to a positive third derivative of the utility function, by Jensen's inequality.

Note that Eq. (5) is positive iff the individual is temperant by the expected utility equivalence of the definition of temperance in[START_REF] Eeckhoudt | Putting risk in its proper place[END_REF]. Now, we see from Eq. (6) that w T ≥ 0 is equivalent to w A is convex by Jensen's inequality. From the definition of w A in Eq. (2) w A is convex iff u is concave, which is equivalent to u (4) ≤ 0 by Jensen's inequality again.

See for example[START_REF] Jean | The geometric mean and stochastic dominance[END_REF][START_REF] Jean | The harmonic mean and other necessary conditions for stochastic dominance[END_REF] or[START_REF] Ingersoll | Theory of Financial Decision Making[END_REF].

We assume throughout this article that the support of any random variable z is defined such that x + z is in the domain of u.

Note that Eq. (10) (respectively (11)) corresponds to cases where Y 2 = 0 and X 2 = -l with l > 0 (respectively X 2 = θ with E( θ) = 0).

The concept of edginess, i.e. u (5) ≥ 0, was introduced by Lajeri-Chaherli (2004) to explain the effects of background risks on precautionary savings.

Risk vulnerability means that risk aversion increases with the presence of an independent background risk[START_REF] Gollier | Risk vulnerability and the tempering effect of background risk[END_REF]. Sufficient and necessary conditions on the utility function to have risk vulnerability are quite complex. A necessary condition for risk vulnerability is u (4) ≤ 0.

This inequality is equivalent to:E[u(x + Y 1 + Y 2 )] + E[u(x + X 1 + X 2 )] ≤ E[u(x + Y 1 + X 2 )] + E[u(x + Y 2 + X 1 )] given byEeckhoudt et al. (2009) to interpret the preference for combining good with bad.


Humberto Leonardo

Marco Tulio Silva

Alexandre Valente

Nicolas Bergel
email: abergel@dcc.uchile.cl

Anne Anquetil

Etien

Leonardo Humberto Silva

Marco Tulio Valente

Alexandre Bergel

Nicolas Anquetil

Anne Etien
email: anne.etien@inria.fr

Identifying Classes in Legacy JavaScript Code

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

JavaScript is the most popular programming language for the Web. The language was initially designed in the mid-1990s to extend web pages with small executable code. Since then, its popularity and relevance only grew [START_REF] Kienle | It's about time to take JavaScript (more) seriously[END_REF][START_REF] Ocariza | JavaScript errors in the wild: An empirical study[END_REF][START_REF] Nederlof | Software engineering for the web: the state of the practice[END_REF]. JavaScript is now the most popular language on GitHub, including newly created repositories. Richards et al. [START_REF] Richards | An analysis of the dynamic behavior of JavaScript programs[END_REF] also reported that the language is used by 97 out of the web's 100 most popular sites. Concomitantly with its increasing popularity, the size and complexity of JavaScript software is in steady growth. The language is now used to implement mail clients, office applications, and IDEs, which can reach hundreds of thousands of lines of code. JavaScript is an imperative and object-oriented language centered on prototypes, rather than a class-based language [START_REF]Standardizing Information and Communication Systems[END_REF][START_REF] Borning | Classes versus prototypes in object-oriented languages[END_REF][START_REF] Guha | The essence of JavaScript[END_REF]. Recently, the new standard version of the language, named ECMAScript 6 (ES6), included syntactical support for classes [START_REF]ECMAScript Language Specification[END_REF]. In this new version, it is possible to implement classes using a syntax very similar to the one provided by mainstream classbased object-oriented languages, like Java and C++. However, there is a large codebase of legacy JavaScript source code, i.e., code implemented in versions prior to the ECMAScript 6 standard.

To mention an example, GitHub has currently over three million active repositories whose main language is JavaScript2 , most of them implemented in ECMAScript 5 (ES5). In this legacy code, developers can emulate class-based abstractions, i.e., data structures including attributes, methods, constructors, inheritance, etc, using the prototype-based object system of the language, which is part of JavaScript since its first version.

In a previous paper, we presented a set of heuristics followed by an empirical study to analyze the prevalence of class-based structures in legacy JavaScript code [START_REF] Silva | Does JavaScript software embrace classes?[END_REF]. This empirical study was conducted on 50 popular JavaScript systems, all implemented according to ES5. The results indicated that: (i) class-based constructs are present in 74% of the studied systems; (ii) there is no correlation between code size and the number of class-like structures; and (iii) emulating inheritance through prototype chaining is not common. In this paper, we extend this previous work as follows:

• We conduct a new study and increase our dataset from 50 to 918 systems. We use an external library called Linguist to allow the extraction of a large dataset from GitHub, ignoring binary or third-party files, and suppressing files generated automatically.

• We perform a field study with 60 professional JavaScript developers to evaluate the accuracy of the proposed strategy to detect class-like structures in legacy JavaScript code.

• We measure precision, recall, and F-score for the identification of classes, methods, and attributes. The overall results range from 97% to 100% for precision, from 70% to 89% for recall, and from 82% to 94% for F-score.

• We investigate if JavaScript developers intend to use the new support for classes that comes with ES6.

The main objective of this work is to propose, implement, and evaluate a set of heuristics to identify class-based structures, and their dependencies, in legacy JavaScript code. Identifying classes in legacy JavaScript code is important for two major reasons. Firstly, it can support developers to migrate their legacy code to ES6, manually or by using tools that rely on the heuristics proposed in this paper. Secondly, it opens the possibility to implement a variety of analysis tools for legacy JavaScript code, including IDEs with class-based views, bad smells detection tools, reverse engineering tools, and techniques to detect violations and deviations in class-based architectures.

The main contributions of our work are as follows: • We document how prototypes are used in JavaScript to support the implementation of structures including both data and code and that are further used as a template for the creation of objects (Section 2). We use the term classes to refer to such structures, since they have a very similar purpose as the native classes from mainstream object-oriented languages.

• We propose a strategy to statically identify classes in JavaScript code (Section 3). We also propose an open source supporting tool, called JSClassFinder, that practitioners can use to detect and inspect classes in legacy JavaScript software.

• We provide a thorough study on the usage of classes in a dataset of 918 JavaScript systems available on GitHub (Section 4). This study aims to answer the following research questions:

(RQ #1) Do developers emulate classes in legacy JavaScript applications? (RQ #2) Do developers emulate subclasses in legacy JavaScript applications? (RQ #3) Is there a relation between the size of a JavaScript application and the number of class-like structures? (RQ #4) What is the shape of the classes emulated in legacy JavaScript code? By "shape of a class" we mean how it is organized in terms of the number of attributes and methods.

• We report the results of a field study with 60 professional JavaScript developers (Section 5).

We rely on these developers to validate our findings and our strategy to detect classes. This study aims to answer the following research questions: (RQ #5) How accurate is our strategy to detect classes? (RQ #6) Do developers intend to use the new support for classes that comes with ECMAScript 6?

The remainder of this paper is organized as follows. Section 2 provides a background on how classes are emulated in legacy JavaScript code using functions and prototypes. Section 3 introduces our strategy and tool to identify classes in JavaScript. Section 4 describes the research questions that guide this work, along with the dataset, metrics, and methodology used in our studies. We show and discuss answers to the proposed research questions in Section 5. We discuss the implications of our results and future research opportunities in Section 6. Threats to validity are exposed in Section 7 and related work is discussed in Section 8. We conclude by summarizing our findings in Section 9.

Classes in JavaScript

In this section, we discuss how classes can be emulated in legacy JavaScript code (Subsection 2.1).

We also describe the syntax proposed in ECMAScript 6 to support classes (Subsection 2.2).

Class Emulation in Legacy JavaScript Code

This section describes the different mechanisms to emulate classes in legacy JavaScript. To identify these mechanisms we conducted an informal survey on documents available on the web, including 5 . We surveyed a catalogue of five encapsulation styles for JavaScript proposed by Gama et al. [START_REF] Gama | Normalizing object-oriented class styles in JavaScript[END_REF] and JavaScript books targeting language practitioners [START_REF] Crockford | JavaScript: The Good Parts[END_REF][START_REF] Flanagan | JavaScript: The Definitive Guide[END_REF]. We also interviewed the developer of a real JavaScript project to tune our tool and strategy. This developer is the leader of the open source project select2 6 (a customizable replacement for select boxes).

An object in JavaScript is a set of name-value pairs. Methods and variables are called properties, and their values can be any objects, including immediate values (e.g., numbers, boolean) and functions. To implement classes in JavaScript, prior to ECMAScript 6 standard, the most common strategy is to use functions. Particularly, any function can be used as a template for the creation of objects. When a function is used as a class constructor, its this is bound to the new object being constructed. Variables linked to this are used to define properties that emulate attributes and methods. If a property is an inner function, then it represents a method, otherwise, it is an attribute. The operator new and the method Object.create(...) are usually used to instantiate classes.

To illustrate the definition of classes in legacy JavaScript code, we use a simple Circle class.

Listing 1 presents the function that defines this class (lines 1-8), which includes two attributes (radius and color) and two methods (getArea and setColor). Functions used to define methods can be implemented inside the body of the class constructor, like getArea (lines 4-6), or outside, like setColor (lines 9-11). An instance of the class Circle is created with the keyword new (line 13). Each object in JavaScript has an implicit prototype property that refers to another object. The instance link between an object and its class in mainstream object-oriented languages is assimilated to the prototype link between an object and its prototype in JavaScript. To evaluate an expression F o r P e e r R e v i e w like obj.p, the runtime system starts searching for property p in obj, then in obj.prototype, then in obj.prototype.prototype, and so on until it finds the desired property or the search fails. When an object is created using new C its prototype is set to the prototype of the function C, which by default is defined as pointing to Object (the global base object in JavaScript). Therefore, a chain of prototype links usually ends at Object. By manipulating the prototype property, we can define methods whose implementations are shared by all object instances. It is also possible to define attributes shared by all objects of a given class, akin to static attributes in class-based languages. In Listing 2, Circle includes a pi static attribute (line 2) and a getCircumference method (lines 5-7). It is worth noting that getCircumference is not attached to the class (as a static method in Java). It has for example access to the object this, whose value is not determined using lexical scoping rules, but instead using the caller object.

1 // prototype property -> static attribute 2 Circle . prototype . pi = 3.14; Listing 2: Using prototype to define methods and static attributes Prototypes are also used to introduce inheritance hierarchies [START_REF] Ungar | SELF: The power of simplicity[END_REF][START_REF] Borning | Classes versus prototypes in object-oriented languages[END_REF]. In JavaScript, we can consider that a class C2 is a subclass of C1 if C2's prototype refers to C1's prototype or to an instance of C1. For example, Listing 3 shows a class Circle2D that extends Circle with its position in a Cartesian plane. Alternatively, the subclass may refer directly to the prototype of the superclass, which is possible using the Object.create() method. This method creates a new object with the specified prototype object, as illustrated by the following code:

1 Circle2D . prototype = Object . create ( Circle . prototype ) Table 1 summarizes the mechanisms presented in this section to map class-based object-oriented abstractions to JavaScript abstractions.

ECMAScript 6 Classes

ECMAScript is the standard definition of JavaScript [START_REF]Standardizing Information and Communication Systems[END_REF]. ECMAScript 6 (ES6) [START_REF]ECMAScript Language Specification[END_REF] is the latest version of this standard, which was released in 2015 7 . Interestingly, a syntactical support to classes is included in this last release. For example, ES6 supports the following class definition: However, this support to classes does not impact the semantics of the language, which remains prototype-based. For example, the previous class is equivalent to the following code:

1 class

Detecting Classes in Legacy JavaScript

In this section, we describe our strategy to statically detect classes in legacy JavaScript source code (Subsection 3.1). Subsection 3.2 describes the tool we implemented for this purpose. We also report limitations of this strategy, mainly due to the dynamic nature of JavaScript (Subsection 3.3).

Strategy to Detect Classes

To detect classes, we reuse with minimal adaptations a simple grammar, originally proposed by This grammar assumes that a program is composed of functions, and that a function's body is an expression. The expressions of interest are the ones that create objects and add properties to functions via this or prototype. However, when functions matching Definition #1 are implemented in the same lexical scope, as functions Circle and setColor in Listing 1, we must distinguish those that are class constructors from those that are methods. To achieve that, we do not consider as a class constructor a function that: (i) has no inner functions bound to this, (ii) does not participate in inheritance relationships defined using prototypes, and (iii) is never instantiated with neither new nor Object.create.

Definition #1: A class is a tuple (C, A, M),
In Listing 1, function setColor does not have inner functions bound to this nor inheritance relationships and it is never instantiated. Therefore, it is not considered a function constructor, but a method of class Circle.

Definition #2: Assuming that (C1, A1, M1) and (C2, A2, M2) are classes in a program P , we define that C2 is a subclass of C1 if one of the following conditions holds:

• P includes an assignment C2.prototype = new C1().

• P includes an assignment C2.prototype = Object.create(C1.prototype).

Tool Support

We implemented a tool, called JSClassFinder [START_REF] Silva | JSClassFinder: A Tool to Detect Class-like Structures in JavaScript[END_REF], for identifying classes in legacy JavaScript programs. As illustrated in Figure 1, this tool works in two steps. In the first step, Esprima 8 -a widely used JavaScript Parser-is used to generate a full abstract syntax tree (AST), in JSON format. In the second step, the "Class Detector" module is responsible for identifying classes in the JavaScript AST and producing an object-oriented model of the source code. The models generated by JSClassFinder are integrated with Moose 9 , which is a platform for software and data analysis [START_REF] Nierstrasz | The story of moose: An agile reengineering environment[END_REF]. This platform provides visualizations to interact with the tool and to "navigate" the application's model. All information about classes, methods, attributes, and inheritance relationships is available. Users can interact with a Moose model to access all visualization features and metric values. This model also allows the use of drill-down and drill-up operations when an entity is selected. The visualization options include UML class diagrams [START_REF] Fowler | UML Distilled: A Brief Guide to the Standard Object Modeling Language[END_REF],

distribution maps [START_REF] Ducasse | Distribution map[END_REF], and tree views. Listing 5: Using closures to implement "private" inner functions In JavaScript, it is possible to remove properties from objects dynamically, e.g., by calling delete myCircle.radius. Therefore at runtime, an object can have less attributes than the ones initially defined. It is also possible to modify the prototype chains dynamically, which would mean modifying the "inheritance" links. Finally, the behavior of a program can also be dynamically modified using the eval operator [START_REF] Richards | The eval that men do: A large-scale study of the use of eval in JavaScript applications[END_REF][START_REF] Meawad | Eval begone!: Semiautomated removal of eval from JavaScript programs[END_REF]. However, we do not consider the impact of eval's in the strategy described in Subsection 3.

Research Questions

Our main goal is to evaluate the strategy we propose to detect class-like abstractions in legacy JavaScript software. To achieve this goal, we pose the following research questions:

• RQ #1: Do developers emulate classes in legacy JavaScript applications?

• RQ #2: Do developers emulate subclasses in legacy JavaScript applications?

• RQ #3: Is there a relation between the size of a JavaScript application and the number of class-like structures?

• RQ #4: What is the shape of the classes emulated in legacy JavaScript code?

• RQ #5: How accurate is our strategy to detect classes?

Metrics

In the following we describe the metrics we use to answer the first four research questions proposed in Subsection 4.1.

Class Density (CD)

To measure the amount of source code related to the emulation of classes (as defined in Subsection 3.1) we use Class Density (CD), which is defined as:

CD = # function methods + # classes # functions
This metric is the ratio of functions in a program that are related to the implementation of classes, i.e., that are methods or that are classes themselves. It ranges between 0 (system with no functions related to classes) to 1 (a fully class-oriented system, where all functions are used to support classes). The denominator includes all functions in a JavaScript program. We use the number of functions to implement methods (function methods) instead of the number of methods because, in JavaScript, it is possible to share the same function to implement multiple methods. Listing 7

shows an example found in the system slick, where a function body is shared by two methods. In this example, the Slick class provides two methods (getCurrent and slickCurrentSlide) that perform the same action when called. Therefore, the number of methods is equal to two, but the number of function methods is one. We used CD to classify the systems in four main groups:

• Class-free systems: systems that do not use classes at all (CD = 0).

• Class-aware systems: systems that use classes, but marginally (0 < CD ≤ 0.25).

• Class-friendly systems: systems with an important usage of classes (0.25 < CD ≤ 0.75)

• Class-oriented systems: systems where most structures are classes (CD > 0.75).

Subclass Density (SCD)

To evaluate the usage of inheritance, we propose the metric Subclass Density (SCD), defined as:

SCD = | { C ∈ Classes | DIT (C ) ≥ 2 } | | Classes | -1
where Classes is the set of all classes in a given system and DIT is the Depth of Inheritance Tree.

Classes with DIT = 1 only inherit from the common base class (Object). SCD ranges from 0 (system that does not make use of inheritance) to 1 (system where all classes inherit from another class, except the class that is the root of the class hierarchy). SCD is only defined for systems that have at least two classes.

Data-Oriented Class Ratio (DOCR)

In a preliminary analysis, we noticed many classes having more attributes than methods. This contrasts to the common shape of classes in class-based languages, when classes usually have more methods than attributes [START_REF] Terra | Qualitas.class Corpus: A compiled version of the Qualitas Corpus[END_REF]. To better understand the members of JavaScript classes, we propose a metric called Data-Oriented Class Ratio (DOCR), defined as follows:

DOCR = | { C ∈ Classes | NOA(C ) > N OM (C) } | | Classes |
where Classes is the set of all classes in a system. DOCR ranges from 0 (system where all classes have more methods than attributes or both measures are equal) to 1 (system where all classes are data-oriented classes, i.e., their number of attributes is greater than the number of methods).

DOCR is only defined for systems that have at least one class.

Field Study Design

To validate our strategy for detecting classes, we perform a field study with the developers of 60 JavaScript applications, including 50 systems from our previous work [START_REF] Silva | Does JavaScript software embrace classes?[END_REF], and 10 new systems.

These systems have at least 1,000 stars on GitHub, 150 commits, and are not forks of other projects.

After checking out each system, we cleaned up the source code to remove unnecessary files, as we did for the dataset described in Subsection 4.2.

The systems considered in the field study are presented in

(R) = TP TP + FN F-score (F 1 ) = 2 × P × R P + R
where TP represents the true positives, FP the false positives, and FN the false negatives. For classes, TP is the number of class-like structures correctly identified by our tool, FP is the number of class-like structures erroneously identified, and FN is the number of existing class-like structures that are not identified. F-score is the harmonic mean of precision and recall. For methods and attributes, the measures are defined in a similar way, but searching for method-like and attributelike structures, respectively.

Results

In this section, we present the answers to the six proposed research questions.

Do developers emulate classes in legacy JavaScript applications?

We found classes in 623 out of 918 systems (68%). The system with the largest number of classes is gaia (1,001 classes), followed by nodeinspector (330 classes), and babylon.js (294 classes).

MathJax is the largest system (122,683 LOC) that does not have classes. The median is 5 and the third quartile is 15 (upper bound of the black box). Listing 8 shows an example of a class Color, detected in the system three.js. We omit part of the code for the sake of readability. False positives for attributes. We have two situations in which methods are indeed identified as attributes in the system angular.js. Listing 10 shows part of the implementation for the class JQLite. Our strategy correctly classifies the property ready (line 2) as a method, but it is not able to do the same with the property splice (line 3). The function [].splice is not recognized as a function because its implementation is not part of the source code of angular.js (it is a JavaScript native function from Array object). Currently, our implementation does not recognize as methods functions that are initialized with JavaScript built-in functions.

Listing 11 shows another example of a property that is not identified as a method in angular.js, as we can see in the following comment:

"$get is marked as attribute a lot, it should always be a method." (Developer of angular.js)

In this case, the property $get receives an array that contains a function in its second element.

Although the developer considers that this property is a method, our approach identifies it as an array and therefore classifies it as an attribute. Listing 10: Example of missing method (line 3 -system angular.js)

Recall

We achieve a recall of 100% in 24 out of 30 systems for classes; in 22 systems for methods; and in 23 systems for attributes. In the following paragraphs we discuss the false negatives we detected for classes, methods, and attributes.

False negatives for classes. Six developers pointed out at least one missing class in their systems. In the case of the system clumsy-bird, the base class constructors are not available in the GitHub repository. The application imports an external file, which contains these base classes. 13 The import statement is placed directly in the main HTML file. For this reason, we were not able to detect classes in this system. As a second case, Express' developer stated that our tool missed two classes, as shown in the following answer excerpt:

"So I have taken a look at the UML diagram you attached to the email and they do look mostly right. The main thing missing is there is also an Application class and a Router class, to round out a total of five main classes. The three you have there do look right, though." (Developer of system

Express)

According to our strategy, Application and Router are not classes. Application is implemented as a singleton object, and we do not identify such structures as classes, as commented in Subsection 3.3. Router is not a class because its methods and attributes are not directly bound to this nor prototype. Instead, the constructor function uses __proto__ (an accessor property), as we can see in Listing 12 (line 5). In fact, __proto__ is a special name used by Mozilla's JavaScript implementation to expose the internal prototype of the object through which it is accessed. However, the use of __proto__ has been discouraged14 , mostly because it is not supported by other browsers.

In the four remaining systems (D3, jasmine, video.js, and Leaflet), the causes for missing

Listing 12: Example of function router which is not detected as a class in system express

False negatives for methods and attributes. In all six systems with missing classes we also have, as consequence, missing methods and attributes. Besides these cases, developers of other two systems pointed out missing methods. In the first case, for system angular.js, our approach identified some methods as attributes, as discussed in the previous subsection (precision). In the second case, paper.js's developers use a customized implementation that allows our approach to identify the classes, but not the methods. Listing 13 illustrates this issue for the class Line. In this case, the association between the constructor Line (line 3) and the methods getPoint(), getVector(), etc (lines 9-11) is built by using a project-specific function called Base.extend (line 1). The usage of this function hides the methods and some attributes from our tool. Listing 13: Class implementation for system paper.js which uses a project-specific function (Base.extend) to implement classes

F-Score

Table 5 also reports the F-score results. The measures are equal to 100% in 22 out of 30 systems for classes, methods, and also for attributes. In the remaining systems, the measures range from 0% (clumsy-bird) to 96% (ace and angular.js) for classes, from 0% (clumsy-bird and leaflet) to 96% (angular.js) for methods, and from 0% (clumsy-bird) to 93% (angular.js) for attributes.

The system clumsy-bird has F-score equal to zero because it uses base class constructors that are not available in its source code repository, as discussed in Subsection 5.5.2.

Overall results

Figure 13 presents the results for precision, recall, and F-score considering the whole population of classes, methods, and attributes, independently from system. The overall measurements range from 97% (classes) to 100% (methods) for precision, from 70% (methods) to 89% (attributes) for recall, and from 82% (methods) to 94% (attributes) for F-score.

Do developers intend to use the new support for classes that comes with ECMAScript 6?

Table 6 summarizes the answers for this question. Nineteen developers (58%) answered that they intend to use the new syntax. Two of them declared to have plans to migrate their systems to the new syntax, while the others stated that they intend to use it only when implementing new features and projects, as stated in the following answer:

"I'm quite confident that ES6 will make for a more robust codebase. And I think the most interesting point is that it can be applied progressively. We don't have to make a massive rewrite. case, when the identifier is assigned to a class property, we can improve our heuristics by checking if this identifier corresponds to a variable or parameter that is valid in the same scope. This way, the property can be classified as an attribute, instead of being wrongly classified as a method. We also acknowledge that, during program's execution, identifiers can receive a function as a value, transforming the class property into a method. However, this is the case of dynamically modified features, and our approach identifies class structures statically. The same understanding can be applied to class properties assigned to functions that are not part of the application, i.e., functions that belong to the JavaScript API or to external libraries and frameworks.

To reduce the chances of false negatives, we can modify the heuristics to also recognize the syntax with __proto__, used by Mozilla's JavaScript implementation, to expose the internal prototype of objects. Even though, as mentioned in Subsection 5.5.2, the use of this syntax has been discouraged by Mozilla. Moreover, we can also review our heuristics regarding singletons.

Since not every singleton object is a class, further research is needed to precisely determine which ones indeed represent classes in a legacy JavaScript system. For the other false negatives pointed in Subsection 5.5, the base class constructors implemented in external files (e.g., in libraries and frameworks) cannot be statically identified as classes because their source code is not part of the system under analysis.

Practical Implications

Almost 70% of the systems we studied use classes (CD > 0). In fact, this usage may increase in the

Threats to Validity

This section presents threats to validity according to the guidelines proposed by Wohlin et al. [START_REF] Wohlin | Experimentation in Software Engineering[END_REF].

These threats are organized in three categories, addressing internal, external, and construct validity.

Internal Validity.

In the field study, to address RQ #5, we recognize three internal threats. First, we consider that the developers correctly evaluated all elements we provided in the class diagrams of their systems. We acknowledge this activity is error-prone. However, we asked the main developers of each system, who are probably the most qualified people to conduct such evaluation. Second, since some developers did not provide the names of all classes that represent false negatives in their systems, the first author of this study performed a manual verification in the related source code files in order to identify the remaining structures. The third internal threat is related to the non classification of singletons as classes, as mentioned in Subsection 3.3. In fact, in our field study some of the interviewed developers considered that singletons are classes.

External Validity. To address the first four research questions, we used a dataset of 918 JavaScript systems. For research questions RQ #5 and RQ #6, which involved contacting developers, we used a dataset of 60 JavaScript systems. As a threat, our datasets, both obtained from GitHub repository, might not represent the whole population of JavaScript systems. But, at least, we selected a representative number of popular and well-known systems, of different sizes and covering various domains.

Construct Validity. We use the library Linguist and a custom-made script, as described in Subsection 4.2, to remove unnecessary files from our dataset. We assume that this clean up process does not remove any source code files that could be used to implement classes.

Related Work

Richards et al. [START_REF] Richards | The eval that men do: A large-scale study of the use of eval in JavaScript applications[END_REF] conduct a large-scale study on the use of eval in JavaScript, based on a corpus of more than 10,000 popular web sites. They report that eval is popular and not necessarily harmful, although its use can be replaced with equivalent and safer code or language extensions in most scenarios. Moreover, it is usually considered a good practice to use eval when loading scripts or data asynchronously. After this first study, restricted to eval's, the authors conduct a second study on a broad range of JavaScript dynamic features [START_REF] Richards | An analysis of the dynamic behavior of JavaScript programs[END_REF]. They conclude for example that libraries often change the prototype links dynamically, but such changes are restricted to built-in types, like

Object and Array, and changes in user-created types are more rare. The authors also report that most JavaScript programs do not delete attributes from objects dynamically. To some extent, these findings support the feasibility of using heuristics to extract class-like structures statically from JavaScript code, as proposed in this paper.

Gama et al. [START_REF] Gama | Normalizing object-oriented class styles in JavaScript[END_REF] identify five styles for implementing methods in JavaScript: inside/outside constructor functions using anonymous/non-anonymous functions and using prototypes. Their main goal is to implement an automated approach to normalizing JavaScript code to a single consistent object-oriented style. They claim that mixing styles in the same code may hinder program comprehension and make maintenance more difficult. The strategy proposed in this paper covers the five styles proposed by the authors. Additionally, we also detect attributes and inheritance.

Feldthaus et al. [START_REF] Feldthaus | Refactoring towards the good parts of JavaScript[END_REF][START_REF] Feldthaus | Toolsupported refactoring for JavaScript[END_REF] describe a methodology for implementing automated refactorings on a nearly complete subset of the JavaScript language (ECMAScript 5 Fard and Mesbah [START_REF] Fard | JSNOSE: Detecting JavaScript code smells[END_REF] propose a set of 13 JavaScript code smells, including generic smells (e.g., long functions and dead code) and smells specific to JavaScript (e.g., creating closures in loops and accessing this in closures). They also describe a tool, called JSNose, for detecting code smells based on a combination of static and dynamic analysis. Among the proposed patterns, only

Refused Bequest is directly related to class-emulation in JavaScript. In fact, this smell was originally proposed to class-based languages [START_REF] Fowler | Refactoring: improving the design of existing code[END_REF][START_REF] Lanza | Object-oriented metrics in practice: using software metrics to characterize, evaluate, and improve the design of object-oriented systems[END_REF], to refer to subclasses that do not use or override many elements from their superclasses. Interestingly, our strategy to detect classes opens the possibility to detect other well-known class-based code smells in JavaScript, like Feature Envy, Large Class, Shotgun Surgery, Divergent Change, etc.

Nicolay et al. [START_REF] Nicolay | Detecting function purity in JavaScript[END_REF] present an abstract machine for a core JavaScript-like language that tracks write side-effects in JavaScript functions to detect their purity. A function is considered pure if it does not generate observable side-effects. Since classes and methods, detected by our strategy, are functions in JavaScript, it is possible to extend the concept of purity to such class-like structures in order to improve program understanding and maintenance.

Nguyen et al. [START_REF] Viet Nguyen | Mining interprocedural, data-oriented usage patterns in JavaScript web applications[END_REF] use a static-analysis-based mining method to mine JavaScript usage patterns in web applications. They introduce JSModel, a graph representation for JavaScript code, and JSMiner, a tool that mines inter-procedural and data-oriented JavaScript usage patterns. Although they do not consider class-like structures in their work, the different strategies for class emulation can be considered usage patterns in JavaScript.

There is also a variety of tools and techniques for analyzing, improving, and understanding JavaScript code, including tools to prevent security attacks [START_REF] Vogt | Cross site scripting prevention with dynamic data tainting and static analysis[END_REF][START_REF] Guha | Using static analysis for Ajax intrusion detection[END_REF][START_REF] Yu | JavaScript instrumentation for browser security[END_REF], and to understand eventbased interactions [START_REF] Alimadadi | Understanding JavaScript event-based interactions[END_REF][START_REF] Zaidman | Understanding Ajax applications by connecting client and server-side execution traces[END_REF][START_REF] Alimadadi | Hybrid DOM-Sensitive Change Impact Analysis for JavaScript[END_REF][START_REF] Gallaba | Don't call us, we'll call you: Characterizing callbacks in JavaScript[END_REF]. CoffeeScript 15 is another language that aims to expose the "good parts of JavaScript" by only changing the language's syntax [START_REF] Bates | Programming in CoffeeScript[END_REF][START_REF] Maccaw | The Little Book on CoffeeScript[END_REF]. CoffeeScript compiles oneto-one into JavaScript code. As ECMAScript 6, the language includes class-related keywords, like class, constructor, extends, etc. This paper provides a large-scale study on the usage of class-based structures in JavaScript, a language that is used nowadays to implement complex single-page applications for the Web. We propose a strategy to statically detect class emulation in JavaScript and the JSClassFinder tool, that supports this strategy. We use JSClassFinder on a corpus of 918 popular JavaScript applications, with different sizes and from multiple domains, in order to describe the usage of classlike structures in legacy JavaScript systems. We perform a field study with JavaScript developers to evaluate the accuracy of our strategy and tool.

We summarize our findings as follows. First, there are essentially four types of JavaScript software, regarding the usage of classes: class-free (systems that do not make any usage of classes), class-aware (systems that use classes marginally), class-friendly (systems that make relevant usage of classes), and class-oriented (systems that have the vast majority of their data structures implemented as classes). The systems in these categories represent, respectively, 32%, 34%, 27%, and 7% of the systems we studied. Precision, recall and F-score measures indicate that our tool is able to identify the classes, methods, and attributes in JavaScript systems. The overall results range from 97% to 100% for precision, from 70% to 89% for recall, and from 82% to 94% for F-score.

Second, we found that there is no significant relation between size and class usage. Therefore, we cannot conclude that the larger the system, the greater the usage of classes, at least in proportional terms. For this reason, we hypothesize that the background and experience of the systems' developers have more impact on the decision to design a system around classes, than its size.

Third, prototype-based inheritance is not popular in JavaScript. We counted only 70 out of 918 systems (8%) using inheritance. We hypothesize that there are two main reasons for this. First, even in class-based languages there are strong positions against inheritance, and a common recommendation is to "favor object composition over class inheritance" [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF][START_REF] Stefanov | JavaScript Patterns[END_REF]. Second, prototype-based inheritance is more complex than the usual implementation of inheritance available in mainstream class-based object-oriented languages.

Fourth, classes in JavaScript have usually less than 28 attributes and 61 methods (90th percentile measures). It is also common to have data-oriented classes, i.e., classes with more attributes than methods. In half of the systems, we have at least 39% of such classes.

Fifth, 58% of JavaScript developers answered our field study saying they intend to use the ES6 new syntax for class emulation, but usually only for new features and projects.

As future work, we plan to adapt our approach to be able to:

1

 1

tutorials 3 ,

 3 blogs 4 , and StackOverflow discussions

1 5 return ( 3 . 14 * 6 } 7 this 1 :

 5314671 function Circle ( radius , color ) { // function -> class 2 this . radius = radius ; // property -> attribute 3 this . color = color ; // property -> attribute 4 this . getArea = function () { // function -> method this . radius * this . radius ) ; . setColor = setColor ; // function -> method 8 } 9 function setColor ( c ) { // function 10 this . color = c ; // property -> attribute 11 } 12 // Circle instance -> object 13 var myCircle = new Circle (10 , 0 x0000FF ) ; // 0 x0000FF = Blue Listing Class declaration and object instantiation

3 4 / 6 return ( 2 *

 462 / function -> method 5 Circle . prototype . getCircumference = function () { this . pi * this . radius ) ; 7 }

  where C is the class name, A = {a 1 , a 2 , . . . , a p } are the attributes defined by the class, and M = {m 1 , m 2 , . . . , m q } are the methods. Moreover, a class (C, A, M), defined in a JavaScript program P , must respect the following conditions:• P must have a function with name C.• For each attribute a ∈ A, the class constructor or one of its methods must include an assignment this.a = Exp or P must include an assignment C.prototype.a = Exp.• For each method m ∈ M, function C must include an assignment this.m = function {Exp} or P must include an assignment C.prototype.m = function {Exp}.

Figure 1 :

 1 Figure 1: JSClassFinder's architecture

1 3 var _ = this ; 4 returnListing 7 :

 347 Slick . prototype . getCurrent = 2 Slick . prototype . slickCurrentSlide = function () { Methods sharing the same body in system slick

Figure 6 (

 6 a) shows the distribution of the number of classes for the systems that have at least one class. The first quartile is two (lower bound of the black box within the "violin") with 135 systems having only one class.

Listing 9 :

 9 Example of method incorrectly identified as a class in angular.js 1 JQLite . prototype = { 2 ready : function ( fn ) {...} ,

  13 http://cdn.jsdelivr.net/melonjs/2.0.2/melonJS.js1 this . $get = [ ' $window ' , function (\ $window ) {...}];Listing 11: Example of an array that contains a function (system angular.js)

2 function

 2 classes are related to the use of external frameworks and libraries that provide their own style for implementing class-like abstractions. The following comments are examples of answers in this category: "The classes you found are only a small part of Leaflet classes. This is because Leaflet uses its own class utility: https://github.com/Leaflet/Leaflet/blob/master/src/core/Class.js" (Developer of system Leaflet) "From a pure Object Orientation point of view, I would probably call almost every file inside 'src / core' in the jasmine repo its own class (minus a few like 'util.js' and 'base.js' at least), which is more like 45 classes." (Developer of system jasmine) 1 var proto = module . exports = function () {

  10 proto . param = function param ( name , fn ) {...}; 11 proto . handle = function () {...}; 12 ...

  future because many developers intend to use the new ECMAScript 6 syntax for classes, as shown in our field study (Subsection 5.6). Therefore, we might consider the adaptation to the JavaScript ecosystem of many tools, concepts, and techniques widely used in class-based languages, like: (a) metrics to measure class properties like coupling, cohesion, complexity, etc; (b) reverse engineering techniques and tools to extract class and other diagrams from source code; (c) IDEs that include class-based views, like class browsers; (d) tools to detect bad smells in JavaScript classes; (e) recommendation engines to suggest best object-oriented programming practices; (f) techniques to detect violations and deviations in the class-based architecture of JavaScript systems; (g) tools to migrate to ECMAScript 6.

  (a) measure other class properties, like coupling, cohesion, and complexity; (b) extract class dependencies and other diagrams from source code; (c) identify bad smells in JavaScript classes; (d) recommend best object-oriented programming practices for JavaScript; (e) detect violations and deviations in the class-based architecture of JavaScript systems; (f) support developers that intend to migrate their legacy code to use ECMAScript 6 classes.

  All our data and toolset are publicly available at https://github.com/aserg-ufmg/ JSClassFinder.

Table 1 :

 1 Class-based languages vs JavaScript

	Class-based languages JavaScript
	Class	Function
	Attribute	Field property
	Method	Inner function property
	Static attribute	Prototype property
	Inheritance	Prototype chaining

  In addition, there are various JavaScript frameworks, like Prototype 10 and ClazzJS 11 , that support their own style for implementing class-like abstractions. For this reason, we do not struggle to cover the whole spectrum of alternatives to implement classes. Instead, we consider only the strategy closest to the syntax and semantics of class-based languages and that ES6 code can be directly translated to (as discussed in Subsection 2.2).Moreover, there are object-oriented abstractions that are more difficult to emulate in JavaScript, like abstract classes and interfaces. Encapsulation is another concept that does not have a straightforward mapping to JavaScript. A common workaround to simulate private members in JavaScript is by using local variables and closures. As shown in Listing 5, an inner function f2 in JavaScript has access to the variables of its outer function f1, even after f1 returns. Therefore, local variables

	F o F o
	r r
	P P
	e e r e e r
	R e v i e w R e v i e w

8

http://esprima.org 9 http://www.moosetechnology.org/ declared in f1 can be viewed as private, because they can only be accessed by the "private function" f2. However, we do not classify f2 as a private method, mainly because it cannot be accessed from the object this, nor can it be directly called from the public methods associated to the prototype of f1. 1 function f1 () { // outer function 2 var x ; // local variable 3 function f2 () { // inner function 4 // can access " x " 5 // cannot be called outside " f1 " 6 } 7 }

  [START_REF] Kienle | It's about time to take JavaScript (more) seriously[END_REF]. For example, we do not account for classes entirely or partially created by means of eval.

	1 function getF () {
	2	// getF () returns another function
	3	return function () {...};
	4 }
	5 function f1 () {	// class constructor
	6	this . x = getF () ; // property x
	7	...
	8 }
		Listing 6: Property that receives a function as the return of a function call
	o F 4 Evaluation Design
			r
			P
			e e r
			R e v i e w
		Still due to the dynamic nature of JavaScript, if a class has a property that receives the return of
	a function call, this property is classified as an attribute, even if this call returns another function.
	Listing 6 shows an example in which the property this.x (line 6) is classified as an attribute, instead
	of a method, because the language is loosely typed and we do not evaluate the results of function
	calls.

In this section, we describe the methodology we use to evaluate and to validate the strategy proposed to detect classes in legacy JavaScript code. We first present the questions that motivate our research (Subsection 4.1). Next, we describe the process we follow to select JavaScript repositories on GitHub and to carry out the necessary clean up of the downloaded code (Subsection 4.2). The metrics we use in our evaluation are described in Subsection 4.3. Finally, we report the design of a field study with JavaScript developers in Subsection 4.4.

Table 2 ,

 2 including their version, a brief description, size (in lines of code), number of files, and number of functions. The selection

	F o
	r
	P
	e e r
	R e v i e w

includes well-known and widely used JavaScript systems, from different domains, covering frameworks (e.g., angular.js and jasmine), editors (e.g., brackets), browser plug-ins (e.g., pdf.js), games (e.g., 2048 and clumsy-bird), etc. The largest system (ace) has 140,023 LOC and 594 files with .js extension. The smallest system (masonry) has 208 LOC and a single file. The average

Table 2 :

 2 JavaScript systems (ordered by the CD column, see description in accompanying text). SCD can only be computed for systems with 2 or more classes. DOCR can only be computed for systems with at least one class.

											Page 18 of 39
	System	Version Description	LOC #Files #Func #Class #Meth #Attr CD SCD DOCR
	masonry	3.2.3 Cascading grid layout library	208	1	10	0	0	0 0.00	-	-
	randomColor	0.2.0 Color generator	373	1	16	0	0	0 0.00	-	-
	respond	1.4.2 Polyfill for CSS3 queries	460	3	15	0	0	0 0.00	-	-
	resume	-	Resume creator	460	1	19	0	0	0 0.00	-	-
	clumsy-bird	-	Flappy Bird Game	672	7	36	0	0	0 0.00	-	-
	impress.js	0.5.3 Presentation framework	769	1	24	0	0	0 0.00	-	-
	jquery-pjax	1.9.3 Plugin to handle Ajax requests	913	1	33	0	0	0 0.00	-	-
	async	1.1.0 Async utilities	1,114	1	100	0	0	0 0.00	-	-
	modernizr	2.8.3 HTML5 and CSS3 detector	1,382	1	69	0	0	0 0.00	-	-
	deck.js	1.1.0 Modern HTML Presentations	1,473	6	51	0	0	0 0.00	-	-
	zepto.js	1.1.6 Minimalist jQuery API	2,497	17	233	0	0	0 0.00	-	-
	photoSwipe	4.0.7 Image gallery	4,401	9	185	0	0	0 0.00	-	-
	semantic-UI	1.12.3 UI component framework	18,369	23	1,191	0	0	0 0.00	-	-
	jQueryFileUp 9.9.3 File upload widget	4,011	14	179	1	1	3 0.01	-	1.00
	leaflet	0.7.3 Library for interactive maps	8,711	75	677	4	0	7 0.01 0.00	1.00
	backbone	1.1.2 Data structure for web apps	1,681	2	115	1	1	0 0.02	-	0.00
	chart.js	1.0.2 HTML5 charts library	3,463	6	189	2	2	5 0.02 0.00	0.50
	turn.js	4.0.0 Page flip effect for HTML5	6,916	5	267	3	3	6 0.02 0.00	1.00
	react	0.13.2 Library for building UI	16,654	143	608	7	8	17 0.02 0.00	0.57
	meteor	1.1.0.2 Development platform	41,195	72	1,378	15	12	14 0.02 0.21	0.20
	underscore	1.8.2 Functional helpers	1,531	1	123	1	5	1 0.03	-	0.00
	jasmine	2.2.1 JavaScript testing framework	7,749	62	892	3	8	11 0.03 0.00	0.67
	paper.js	0.9.22 Vector graphics framework	26,039	65	1,071	30	10	115 0.04 0.00	0.90
	typeahead.js	0.10.5 Auto-complete library	2,576	19	233	11	1	72 0.05 0.00	1.00
	d3	3.5.5 Visualization library	13,079	268	1,259	19	45	41 0.05 0.22	0.58
	wysihtml5	0.3.0 Rich text editor	5,913	69	343	2	17	8 0.06 0.00	0.00
	sails	0.11.0 MVC framework for Node	12,724	101	425	8	23	40 0.07 0.00	0.25
	ionic	1.0.0.4 HTML5 mobile framework	19,322	103	492	8	26	21 0.07 0.29	0.50
	jquery	2.1.4 jQuery JavaScript library	7,736	79	330	6	25	31 0.09 0.00	0.50
	ghost	0.6.2 Blogging platform	15,290	142	659	15	47	44 0.09 0.00	0.27
	timelineJS	2.35.6 Visualization chart	18,371	93	896	12	69	11 0.09 0.00	0.08
	express	4.12.3 Minimalist framework	3,590	11	131	3	12	14 0.11 0.00	0.67
	reveal.js	3.0.0 HTML presentation framework	5,811	16	242	5	22	18 0.11 0.00	0.40
	video.js	4.12.5 HTML5 video library	9,823	46	586	6	63	17 0.11 0.00	0.50
	three.js	0.0.71 JavaScript 3D library	39,449	202	1,266	99	48	544 0.12 0.00	0.92
	numbers.js	-	Mathematics library for Node	2,965	10	132	2	16	4 0.14 0.00	0.00
	polymer	0.5.5 Library for building web apps	11,849	1	763	22	103	68 0.16 0.00	0.41
	grunt	0.4.5 JavaScript task runner	1,932	11	103	1	16	8 0.17	-	0.00
	skrollr	0.6.29 Scrolling library	1,772	1	58	1	12	0 0.22	-	0.00
	ace	1.1.9 Source code editor	140,023	594	4,337	291	673	785 0.22 0.01	0.46
	mousetrap	1.5.3 Library for handling shortcuts	1,281	5	46	1	10	0 0.24	-	0.00
	hammer.js	2.0.4 Handle multi-touch gestures	2,348	19	124	6	33	25 0.31 0.00	0.33
	brackets	1.3.0 Source code editor	130,770	392	4,298	173	1,239	750 0.33 0.09	0.31
	angular.js	1.4.0.1 Web application framework	49,220	191	981	61	276	171 0.34 0.03	0.21
	intro.js	1.0.0 Templates for introductions	1,255	1	42	1	14	2 0.36	-	0.00
	algorithms	0.8.1 Data structures & algorithms	3,263	58	165	14	59	32 0.44 0.23	0.21
	pdf.js	1.1.1 Web PDF reader	57,359	88	2,277	181	895	795 0.47 0.11	0.44
	bower	1.4.1 Package manager	8,464	60	304	15	143	97 0.51 0.00	0.40
	mustache.js	2.0.0 Logic-less template syntax	594	1	33	3	15	7 0.55 0.00	0.33
	less.js	2.3.1 CSS pre-processor	12,045	99	707	64	327	278 0.55 0.21	0.34
	gulp	3.8.11 Streaming build system	99	3	5	1	2	6 0.60	-	1.00
	fastclick	1.0.6 Library to remove click delays	841	1	23	1	16	10 0.74	-	0.00
	pixiJS	3.0.2 Rendering engine	21,024	113	703	87	453	546 0.76 0.33	0.46
	isomer	0.2.4 Isometric graphics library	770	7	47	7	31	27 0.81 0.00	0.57
	2048	-	Number puzzle game	873	10	76	7	62	29 0.91 0.00	0.14
	slick	1.5.2 Carousel visualization engine	2,300	1	81	1	86	0 0.93	-	0.00
	floraJS	3.1.1 Simulation of natural systems	2,942	20	86	18	62	315 0.93 0.00	0.94
	parallax	2.1.3 Motion detector for devices	1,007	3	57	2	56	75 0.95 0.00	1.00
	jade	1.9.2 Template engine for Node	11,427	27	169	19	142	73 0.95 0.83	0.26
	socket.io	1.3.5 Realtime app framework	1,297	4	57	4	58	46 1.00 0.00	0.00
			http://mc.manuscriptcentral.com/jsme

Table 5 :

 5 Precision, Recall, and F-Score results

	4 };
	5 THREE . Color . prototype = {
	6	r : 1 , g : 1 , b : 1 , // Attributes
	7	// Methods
	8	setRGB : function ( r , g , b ) { ... } ,

1 THREE . Color = function ( color ) { // Constructor 2 ...

3 return this . set ( color ) 9 ... 10 } Listing 8: Example of class in three.js

  rename property is similar to the refactoring rename field for typed languages. The main difference is that while fields in Java, for example, are statically declared within class definitions, properties in JavaScript are associated with dynamically created objects and are themselves dynamically created after first write. The goal of the refactoring extract module is to use anonymous functions to make global functions become local. These anonymous functions will then return object literals with properties through which the previous global functions can be invoked. The encapsulate property refactoring can be used to encapsulate state by making a field private and redirecting access to that field via newly introduced getter and setter methods. It targets constructor functions that emulate classes in JavaScript. To determine if a function works as a constructor, they look for functions that initialize an object when invoked, like those that are invoked with new or Object.create().

	F o
	r
	P
	e e r
	R e v i e w

). The authors specify and implement three refactorings: rename property, extract module, and encapsulate property. The

http://githut.info/

http://mc.manuscriptcentral.com/jsme Journal of Software: Evolution and Process

https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in _Mozilla

Journal of Software: Evolution and Process

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto

Acknowledgments

The authors would like to thank CNPq, CAPES and FAPEMIG. This research is partially supported by STICAmSud project 14STIC-02 and FONDECYT 1160575.