On 03/01/2011 01:50 AM, Stewart Gordon wrote:
Trouble is it would create fragility, as parameter names would become a new thing that can't be changed once decided without breaking existing code. So it would be important to get them right from the beginning, and there'll be a time when the feature has just been introduced during which library programmers are in the process of changing parameter names to something meaningful. But one way around that would be to support parameter aliases, which would also confer a few more benefits.
That is a real concern, indeed, and the only rational point until now possibly interpretable against named parameters: once a lib is adopted, the feature freezes param names --just like type names, funcs names, member names, constant names, alias names and so on and so forth. On the other hand, this will hopefully prevent lib authors using meaningless/helpless names from the start on ;-) It may even help & promote de facto or discussed conventions on param names (ideally, one would be able to guess half of them from the /meaning/ of parameters)
Denis -- _________________ vita es estrany spir.wikidot.com
