Tfpt review /shelveset:NewMethodBinder;tomat
Affects outer DLR, Python, Ruby.
DLR, Python
Redesigns the default method binder:
- Merges ParameterBinder into MethodBinder, moves virtual methods
related to CLR method binding and parameter conversions from ActionBinder and
DefaultBinder to MethodBinder.
- MethodBinder is now an abstract class that provides virtuals that
languages can override. DefaultMethodBinder provides simple implementation that
languages can base their binders on or directly use.
- Enables "partially restricted splatting" feature (only
implemented in Ruby so far, but should be relatively easy to generalize it and
use it by default):
- Previous implementation required languages to pass the binder an
array of meta-objects including all items of the splatted array. This is not
feasible for splatting arrays containing thousands of items (StackOverflow
exception occurred in a Ruby library due to an expression of depth greater than
5k constructed as a rule condition). The new implementation allows the binder to
only construct such conditions and restrictions that are necessary to decide
which overload to select. In the worse case, which occurs e.g. when the overload
set is { foo(params int[]), foo(params object[]) } and the call-site is
foo(*([1]*10000 + [''x''])) , the condition that decides whether
an overload/rule is applicable is implemented using a loop rather than
disjunction of 10001 type equality expressions. Usually, the overload could be
selected by splatting the array partially, using few items of the array from
beginning and/or end of the array. More optimizations to the partial splatting
are certainly possible - those should be easy to implement on top of the new
method binder architecture if needed.
- MethodBinder builds its state in several steps (see ResolveOverload
method):
1) TargetSets and MethodCadnidates are built - MethodCandidate represents a
CLR method overload tailored to a fixed arity (a follow-up refactoring will
merge MethodTarget into MethodCandidate, they map 1:1). TargetSet represents a
set of MethodCandidates (CanidateSet would be a better name - will rename in a
follow-up change) that match the same arity. Building MethodCandidates involve
creating ParameterWrappers and ArgBuilders. This process can be customized by
languages. Languages can define their own wrappers and builders, their own
dictionary and array splatting mechanisms.
2) The ActualArguments class is created (this is also customizable by
languages). ActualArguments instance holds on meta-objects of positional and
named arguments, actual argument names, and various indices needed for
splatting.
3) TargetSet with arity corresponding to the number of actual arguments is
created. If the binder implements partial splatting, the array is splatted to
match arities of existing target sets but no more. The rest of the arguments
(those that were not extracted from the array) are referred to as
"collapsed" and are dealt with separately during overload resolution.
The previous implementation of "MakeBindingTarget" is replaced by a
new one, which fixes issues with named arguments and also takes collapsed
arguments into consideration. It has several steps:
a. Match actual names of the arguments with parameter names, calculate
permutations that map indices of the former to the latter, and filter out
MethodCandidates whose parameter names don''t match. The result of this
step is a set of ApplicableCandidates, each ApplicableCandidate comprises of a
MethodCandidate and a ArgumentBinding permutation.
b. Then for each narrowing level: Non-collapsed arguments are tested for
convertibility to the parameter types of the applicable overloads. Those
overloads that don''t match are removed from applicable candidates set.
If no overloads remain, it''s an error. If a single overload remains we
successfully chosen the overload (note that collapsed arguments don''t
need to be visited in this case). Otherwise we check whether collapsed arguments
can all be converted to the element type of the corresponding params-array.
Again, if no candidate remains, we failed. If a single one remains we succeeded.
Otherwise we continue by comparing various conversions and selecting the best
ones based on the current narrowing level.
- During these steps the MethodBinder builds its state (candidate sets,
actual arguments, etc.) and derived method binders can also remember some
additional data/state that is used for building arguments or error reporting
(temporary variable that stores the splattee, restrictions/conditions used for
splatting, the signature of the call-site, etc.). The MethodBinder should be
instantiated with all information that doesn''t change during overload
resolution (the "input" to the overload resolution).
- Renames ParameterBinderWithCodeContext to PythonMethodBinder and
moves it to Python.
- Moves SiteLocalStorage to Python. Ruby uses a different storage class
and it''s very simple for languages to define and use their own.
- ActionBinder.BindSpecialParameter shouldn''t deal with
CodeContext and SiteLocalStorage - moved to PythonMethodBinder.
- Moved ContextArgBuilder and SiteLocalStorageArgbuilder to Python.
- ArgBuilder.CanGenerateDelegate needs to be protected so that custom
ArgBuilders can override it.
- Improves errors reported by the method binder.
- Removes old call, invoke and operation actions and related code.
Ruby:
- Replaces calls to obsolete methods of default method binder with
those using meta-objects.
- Implements partially restricted splatting.
Fixes http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=18379.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20090407/d4e890b5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NewMethodBinder.diff
Type: application/octet-stream
Size: 195886 bytes
Desc: NewMethodBinder.diff
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20090407/d4e890b5/attachment-0001.obj>