Re: signature subtyping and role merging
HaloO, Jonathan Lang wrote: If you're not using "multi", then the signature is superfluous for type-checking purposes. I think that signatures do matter for type-checking! It is an error to provide too few or to many positional args or args with an incompatible type. Regards, TSa. --
Re: signature subtyping and role merging
HaloO, TSa wrote: When names have to be available as well, then we get an undefined method that has to have two positionals and two named parameters such that all four names appear to satisfy all conceivable call sites for the two roles. To get four names for two positional Parameters an 'is alias' parameter trait is needed that can be given several times to produce an alias that can be used as key in the named argument binding. Such a trait is also very useful for backwards compatibility when parameter names are changed. The signature merger would set alias traits as needed. I don't know how the routine that is put behind the signature determines in which context it was called to correctly swap the arguments for the backend doit routine. Ideas? Regards, TSa. --
Re: signature subtyping and role merging
TSa wrote: Jonathan Lang wrote: > If you're not using "multi", then the signature is superfluous for > type-checking purposes. I think that signatures do matter for type-checking! It is an error to provide too few or to many positional args or args with an incompatible type. Mea culpa. I thought you were still talking about using an object's methods as part of the process of deciding whether or not that object satisfies the role requirements of some other routine's signature. Of course signatures matter when it comes to deciding which arguments that method will accept. -- Jonathan "Dataweaver" Lang
