Named parameters?

[Daniel O'Connell [C# MVP]]

Re: Named parameters?


"cody" <deutronium@gmx .de> wrote in message
news:uRCJA0hWFH A.3712@TK2MSFTN GP09.phx.gbl...[color=blue][color=green][color=darkred]
>>>> It adds support for a (IMHO) better design pattern than optional
>>>> parameters, thoughts anyone?
>>>
>>>
>>> Anders Hejlsberg spoke in a panel about a new syntax proposal for
>>> creating objects (not just for parameter passing). It was something like
>>> that:[/color]
>>
>> What panel was that?[/color]
>
> I found it on msdn TV, just look into the archives of microsoft.com after
> "csharp features - AndersHejlsberg _300.wmv".
>[color=green][color=darkred]
>>> But then you cannot do something like that:
>>>
>>> Point p = new Point{X=10, Y=X}
>>>
>>> because you cannot access X from there. In that case you have to use my
>>> proposed character which distinguishes between a property of that object
>>> and a local variable.
>>>[/color]
>>
>> Which is a wholely bad idea, IMHO. You wouldn't do new Point(10, X)
>> either. I don't really see how this relates to named parameters either.[/color]
>
> It would make it easier/less verbose to create parameter objects.
>[color=green]
>> I really think adding a character to distinguish between properties and
>> variables is one step into turning the langauge into a mess not worth
>> working with.[/color]
>
> Maybe you're right. A character for distinguishing was just a suggestion,
> maybe not a good one.
>[/color]

Sorry for getting back so late, either my newsreader or the MS servers just
decided to give me about 200 entries I missed.

I do not like distingishing characters(even for the set thing we talked
about a while back, I still havn't figured out a way to keep things
consistent AND allow string and other IENumerables to be atomic units
without a distingusihing character or operator). Expanded object
construction that allows for blocks of property setters wouldn't be bad,
though.

[cody]

Re: Named parameters?

> I do not like distingishing characters(even for the set thing we talked[color=blue]
> about a while back, I still havn't figured out a way to keep things
> consistent AND allow string and other IENumerables to be atomic units
> without a distingusihing character or operator).[/color]

Yes C# is not a language where lots of special chars and operators fits in,
C# is more a "keyworded language".
The problem is that you cannot add keywords afterwards, only "context-only
keywords" like "yield" or "value".
If I would be a language designer creating a new language I'd reserve lots
of potential keywords at first, just in case they'll be needed at some time.
[color=blue]
> Expanded object construction that allows for blocks of property setters
> wouldn't be bad, though.[/color]

If we allow the property setters of the object only on the left side there
is no problem with ambiguity.

[Daniel O'Connell [C# MVP]]

Re: Named parameters?


"cody" <deutronium@gmx .de> wrote in message
news:ewN4wiuXFH A.3620@TK2MSFTN GP09.phx.gbl...[color=blue][color=green]
>> I do not like distingishing characters(even for the set thing we talked
>> about a while back, I still havn't figured out a way to keep things
>> consistent AND allow string and other IENumerables to be atomic units
>> without a distingusihing character or operator).[/color]
>
> Yes C# is not a language where lots of special chars and operators fits
> in, C# is more a "keyworded language".[/color]

Ya, it is a weirdly half "explicit-for-the-sake-of-explicity", half
"implicit-for-the-sake-of-simplicity" language. How else can you explain all
the little quirks that don't add up with all the other ones unless you look
at the langauge in historical context and as a whole. Looking at C#
piecemeal is depressing. The casting operator is wholly unlike anything else
in the language, 'as' is strange in that it is a casting operator that
doesn't look like the other casting operator, instead it matches up with
'is'(which is effectivly a cast that looks and acts like a comparison).
There is no explicit conversion operator, but there are explicit
conversions(whi ch use the cast operator, brilliant). Yet, look at it from a
realistic, users point of view and it is simple, easy to use, and very
effective.
[color=blue]
> The problem is that you cannot add keywords afterwards, only "context-only
> keywords" like "yield" or "value".[/color]

Eventually, the standard is going to have to expand to add new keywords or
the language will falter. I am not sold on going the whole-hog java route of
doing everything possible, including sacrificing functionality or
consistency, to keep old code compiling in new compilers.

I think migration tools might be the way to go here, something that can be
run across code and will change varaible names safely(detect collisions,
etc) and output a changlog file showing *exactly* waht changed(which VS
should be able to process and show us, ;)

Then again, spaced and contextual keywords aren't hard to understand and
might end up being a solution to the whole problem.
[color=blue]
> If I would be a language designer creating a new language I'd reserve lots
> of potential keywords at first, just in case they'll be needed at some
> time.
>[/color]
This can be hard to do, because its so easy to say you want to reserve:
index
value
param
arg

etc, taking up half of the common variable name set, ;). Plus, inevitably,
you'd find a feature you wanted to add that didn't work with the words you
already had restricted. Still, the C# team should have atleast thought
forward to generics and other 2.0 features, which were likely on the drawing
board already, and reserved the keywords they could.

Also, didn't C++ try this with underscores? The system reserved all
identifiers starting with two underscores or somethign like that, thats why
things like __int64 got so popular(and possibly one of the reasons C++ has
as much of a readability stigma attached to it as it does).
[color=blue][color=green]
>> Expanded object construction that allows for blocks of property setters
>> wouldn't be bad, though.[/color]
>
> If we allow the property setters of the object only on the left side there
> is no problem with ambiguity.[/color]

No, there isn't. It certainly is an interesting concept. Curious, curious. I
need to get back to my compiler one of these days, the list of ideas to
implement keeps getting longer and longer.