Pokrewne
- Strona Główna
- Professional Feature Writing Bruce Garrison(6)
- Bruce Robert Nowe Drogi Energii
- Professional Feature Writing Bruce Garrison(4)
- Professional Feature Writing Bruce Garrison(3)
- Professional Feature Writing Bruce Garrison(1)
- Professional Feature Writing Bruce Garrison
- Professional Feature Writing Bruce Garrison(5)
- Assembly Language, Step by Step by Jeff Duntemann
- Paul Williams Mahayana Buddhism The Doctrinal Foundations, 2008
- Ursula K. Le Guin Tehanu
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- opowiastki.keep.pl
[ Pobierz całość w formacie PDF ]
.In Java, when a programmer calls an overloaded method, the compilerdetermines which version of the method to call based on the name and thestatic types of the parameters.Of course the actual method body to executeis determined dynamically based on the run-time type of the receiver, butwhich version (i.e., which extended name for the method) to use is deter-mined statically.In a multi-method language, the selection of which methodto execute is determined at run time based on the types of the values of theactual parameters.2Going back to the example above, suppose we evaluateequal(pt1,pt2)where at run timept1is a value of typePointandpt2is a value of typeColorPoint.In this case, using the body of the second version ofequalwould not be possible because the first parameter has run-time typePoint,and hence would not conform to the declaration that the first parameter havetypeColorPoint.As a result the first method body must be chosen.In general, multi-method languages search in a predetermined way to findthe appropriate best match among the available method bodies.In thesecond example above, where both parameters were actually of typeCol-orPointat run time, either of the method bodies might have been called,2.Of course in a multi-method language the system may be able to make some decisions onwhich version of the method to execute based on statically available information as well.Ifone version has two formal parameters and another has three, that information can be used toeliminate method versions statically. 100 7 Varieties of Object-Oriented Programming Languagesbut the second was a better match because the run-time types were exactlythe declared types of the formal parameters.The first example, where both parameters werePoints, and the third ex-ample, where the first parameter was aPointand the second parameterwas aColorPoint, were both easy because the types of the actual param-eters conformed to only one of the method bodies the first.In some cases,however, the choice of method body to use is not as obvious as for the threecases we have seen so far.Suppose we define the following methods:function compare(p1:Point, p2:ColorPoint): Boolean is{ return.}function compare(p1:ColorPoint, p2:Point): Boolean is{ return.}Acall ofcompare(pt1,pt2)forpt1andpt2, where both have statictypePoint, would not be statically type safe because there is nocomparemethod with signature accepting two values of typePoint.Instead, thereare method bodies corresponding to any call involving onePointand oneColorPoint.Suppose we writecompare(cpt1, cpt2), wherecpt1andcpt2both have typeColorPoint.If the two definitions above are the onlydefinitions ofcompare, we now have a problem.If the run-time types ofcpt1andcpt2areColorPoint(or indeed any subtype ofColorPoint),it is no longer clear what is the best choice for the method body to be exe-cuted.Each method choice matches one of the parameters exactly, but theother parameter is better matched by the other version of the method.For each method call at run time, multi-method languages generally firstdetermine the set of possible method bodies that might be executed.If thereis only one, then there is no problem, otherwise an attempt is made to findthe version of the method with the best fit.The difficulty arises when thereis no clear best fit as in the situation described above withcompare.Different multi-method languages handle this problem in different ways.Some languages (CLOS [DG87], for example) provide rules to specify whichmethod body is to be chosen when there is more than one match, while oth-ers (Cecil [Cha95], for example) require the programmer to disambiguate thecalls by inserting one or more new method definitions to resolve the ambigu-ous cases.If the first way of handling ambiguities is chosen, the language might spec-ify, for example, that first a best fit among the matching method bodies isYLFMAET 7.1 Multi-methods vs.object-based vs.class-based languages 101found for the first argument , and then for successive arguments.If we wereto use this rule, then the call ofcompare(cpt1, cpt2)would result in theexecution of the second method body, because it provides the best match forthe first argument.If the second way of handling ambiguities is chosen, the type system mightrequire the programmer to explicitly add a new method body for the casewhere both parameters are of typeColorPointas that eliminates all ambi-guities in resolving method calls forcompare.While Java is not a multi-method language, it does complain about over-loaded methods that it cannot resolve statically, and insists that the program-mer disambiguate such expressions.An example would be a class containingoverloaded methods with two parameters whose corresponding types are inopposite subtyping relations like those in thecomparemethods above.A major advantage of multi-method languages is in the handling of binarymethods.Because there is no designated receiver of the message, all param-eter values involved in the computation have equal precedence (aside fromorders specified to resolve ambiguities as noted above).Thus ifmis desiredto be a binary method, programmers can simply ensure that the types forboth parameters are the same for all method definitions ofm.For example, our definitions of the method bodies forequal, above, eachsatisfy the constraint that the types of the two parameters are identical.Ascan be seen in the examples above, this does not prevent us from callingtheequalmethod with parameters of different types.Thus we could writeequal(pt1,pt2), where the value of one of the arguments was of typePointand the other was of typeColorPoint, but we will always have thatpossibility in languages with subtyping [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl agnieszka90.opx.pl
.In Java, when a programmer calls an overloaded method, the compilerdetermines which version of the method to call based on the name and thestatic types of the parameters.Of course the actual method body to executeis determined dynamically based on the run-time type of the receiver, butwhich version (i.e., which extended name for the method) to use is deter-mined statically.In a multi-method language, the selection of which methodto execute is determined at run time based on the types of the values of theactual parameters.2Going back to the example above, suppose we evaluateequal(pt1,pt2)where at run timept1is a value of typePointandpt2is a value of typeColorPoint.In this case, using the body of the second version ofequalwould not be possible because the first parameter has run-time typePoint,and hence would not conform to the declaration that the first parameter havetypeColorPoint.As a result the first method body must be chosen.In general, multi-method languages search in a predetermined way to findthe appropriate best match among the available method bodies.In thesecond example above, where both parameters were actually of typeCol-orPointat run time, either of the method bodies might have been called,2.Of course in a multi-method language the system may be able to make some decisions onwhich version of the method to execute based on statically available information as well.Ifone version has two formal parameters and another has three, that information can be used toeliminate method versions statically. 100 7 Varieties of Object-Oriented Programming Languagesbut the second was a better match because the run-time types were exactlythe declared types of the formal parameters.The first example, where both parameters werePoints, and the third ex-ample, where the first parameter was aPointand the second parameterwas aColorPoint, were both easy because the types of the actual param-eters conformed to only one of the method bodies the first.In some cases,however, the choice of method body to use is not as obvious as for the threecases we have seen so far.Suppose we define the following methods:function compare(p1:Point, p2:ColorPoint): Boolean is{ return.}function compare(p1:ColorPoint, p2:Point): Boolean is{ return.}Acall ofcompare(pt1,pt2)forpt1andpt2, where both have statictypePoint, would not be statically type safe because there is nocomparemethod with signature accepting two values of typePoint.Instead, thereare method bodies corresponding to any call involving onePointand oneColorPoint.Suppose we writecompare(cpt1, cpt2), wherecpt1andcpt2both have typeColorPoint.If the two definitions above are the onlydefinitions ofcompare, we now have a problem.If the run-time types ofcpt1andcpt2areColorPoint(or indeed any subtype ofColorPoint),it is no longer clear what is the best choice for the method body to be exe-cuted.Each method choice matches one of the parameters exactly, but theother parameter is better matched by the other version of the method.For each method call at run time, multi-method languages generally firstdetermine the set of possible method bodies that might be executed.If thereis only one, then there is no problem, otherwise an attempt is made to findthe version of the method with the best fit.The difficulty arises when thereis no clear best fit as in the situation described above withcompare.Different multi-method languages handle this problem in different ways.Some languages (CLOS [DG87], for example) provide rules to specify whichmethod body is to be chosen when there is more than one match, while oth-ers (Cecil [Cha95], for example) require the programmer to disambiguate thecalls by inserting one or more new method definitions to resolve the ambigu-ous cases.If the first way of handling ambiguities is chosen, the language might spec-ify, for example, that first a best fit among the matching method bodies isYLFMAET 7.1 Multi-methods vs.object-based vs.class-based languages 101found for the first argument , and then for successive arguments.If we wereto use this rule, then the call ofcompare(cpt1, cpt2)would result in theexecution of the second method body, because it provides the best match forthe first argument.If the second way of handling ambiguities is chosen, the type system mightrequire the programmer to explicitly add a new method body for the casewhere both parameters are of typeColorPointas that eliminates all ambi-guities in resolving method calls forcompare.While Java is not a multi-method language, it does complain about over-loaded methods that it cannot resolve statically, and insists that the program-mer disambiguate such expressions.An example would be a class containingoverloaded methods with two parameters whose corresponding types are inopposite subtyping relations like those in thecomparemethods above.A major advantage of multi-method languages is in the handling of binarymethods.Because there is no designated receiver of the message, all param-eter values involved in the computation have equal precedence (aside fromorders specified to resolve ambiguities as noted above).Thus ifmis desiredto be a binary method, programmers can simply ensure that the types forboth parameters are the same for all method definitions ofm.For example, our definitions of the method bodies forequal, above, eachsatisfy the constraint that the types of the two parameters are identical.Ascan be seen in the examples above, this does not prevent us from callingtheequalmethod with parameters of different types.Thus we could writeequal(pt1,pt2), where the value of one of the arguments was of typePointand the other was of typeColorPoint, but we will always have thatpossibility in languages with subtyping [ Pobierz całość w formacie PDF ]