Denis Koroskin wrote:
> I once had the following Color class:
> 
> class Color
> {
>     this (byte alpha, byte red, byte green, byte blue) { ... }
> }
> 
> and used it as follows:
> 
> Color c = new Color(255, 0, 255, 0); // opaque green color
> 
> After refactoring, alpha became last argument in ctor:
> 
>     this(byte red, byte green, byte blue, byte alpha) { ... }
> 
> Note that this change didn't raise any compilation error, nothing that would notify my of possible error.
> 
> Needless to say that I didn't enjoy searching all the code that used Color to reorder parameters (although some artifact were nice :)
> It would save me quite some time if I initialized all my instances as follows:
> 
> Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);
> 
> Now compiler could raise an error if parameters order was changed. Even better - compiler could reorder parameters for me automatically if given that all of them are specified and no params ommited (unlike Python). This makes code more robust to refactoring.

The first thing  I thought of when reading this is Eclipse JDT's "Change Method Signature" refactoring that will look up all the calls in your project & automatically reorder the parameters for you.

On Wed, 29 Oct 2008 18:49:53 -0200, Ary Borenszweig wrote:

> bearophile escribió:
>> Denis Koroskin:
>> 
>>> graphicsDevice->updateSettings(fullScreen: true, verticalSync: true, enableBloom: false, fullScreenAA: true);
>> 
>> Seeing this, now I think the syntax with equals is a little shorter, so maybe I prefer the equals:
>> 
>> graphicsDevice->updateSettings(fullScreen=true, verticalSync=true, enableBloom=false, fullScreenAA=true);
> 
> You didn't just replace ":" for "=", you also removed spaces! :P
> 
> graphicsDevice->updateSettings(fullScreen:true, verticalSync:true, enableBloom:false, fullScreenAA:true);
> 
> graphicsDevice->updateSettings(fullScreen=true, verticalSync=true, enableBloom=false, fullScreenAA=true);
> 
> See? Now they are the same length.
> 
> It's not a matter of preference in D, because "a=b" is an expression, so "=" can't be used for named arguments. I think ":" can, because that is used in statements... and in ?:, but there would be no ambiguities there.

His point was that after typing ':' he will usually put a space. I don't really understand this argument, as I know of people that will complain when spaces aren't put around ' = '.

I do like the idea of name the arguments in the call for readability. I don't think it should be mandatory, nor do I believe anyone has suggested that.

Robert Fraser escribió:
> Denis Koroskin wrote:
>> I once had the following Color class:
>>
>> class Color
>> {
>>     this (byte alpha, byte red, byte green, byte blue) { ... }
>> }
>>
>> and used it as follows:
>>
>> Color c = new Color(255, 0, 255, 0); // opaque green color
>>
>> After refactoring, alpha became last argument in ctor:
>>
>>     this(byte red, byte green, byte blue, byte alpha) { ... }
>>
>> Note that this change didn't raise any compilation error, nothing that would notify my of possible error.
>>
>> Needless to say that I didn't enjoy searching all the code that used Color to reorder parameters (although some artifact were nice :)
>> It would save me quite some time if I initialized all my instances as follows:
>>
>> Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);
>>
>> Now compiler could raise an error if parameters order was changed. Even better - compiler could reorder parameters for me automatically if given that all of them are specified and no params ommited (unlike Python). This makes code more robust to refactoring.
> 
> The first thing  I thought of when reading this is Eclipse JDT's "Change Method Signature" refactoring that will look up all the calls in your project & automatically reorder the parameters for you.

Me too. :-)

bearophile wrote:
> Julio César Carrascal Urquijo:
>> Actually Boo supported the same thing before them. Their IQuakFoo interface it's the equivalent of the IDinamicObject interface in C# 4.
> 
> When the LDC compiler works well (based on LLVM) I think the underlying VM may be used in ways similar to the dotnet VM or the JavaVM, so you can even think about putting in the D language more reflection, some native forms of dynamic generation and compilation of code, that today are possible in C#, macros like ones in Boo, etc.

This seems to be a common misconception.
LLVM doesn't actually have a VM in the traditional sense. It provides a virtual instruction set, but there's no common abstractions other than basic types (integers, floats), vectors of them, structs, static arrays, pointers, functions and global variables (I hope I didn't miss anything). Anything else has to be synthesized from those elements by whatever compiler frontend (or hand-coder -- not recommended) generates the instructions.

For example: there are no "virtual functions" in LLVM. There's just structs whose first member happens to be a pointer to a global constant array (or struct) of function pointers that can take a pointer to the struct as their first argument.

In other words: every language compiling to LLVM translates its high-level abstractions into those low-level types. And every one of them probably does it in a slightly different way.
It's more like a sort of typed, somewhat-platform-independent assembly designed for ease of optimization.
It's usually compiled to native code, so LLVM typically isn't even loaded into memory at the time your code is running. There's an interpreter and a JIT, but neither of these expose any kind of reflection API usable by the program they're running.

LLVM is being used to _implement_ a dotnet and Java VM, but it's not much like such a VM in itself.

bearophile Wrote:

> Seeing this, now I think the syntax with equals is a little shorter, so maybe I prefer the equals:
> 
> graphicsDevice->updateSettings(fullScreen=true, verticalSync=true, enableBloom=false, fullScreenAA=true);
> 
this breaks C look and feel (that's why in C# it's a colon).

Frits van Bommel:
> This seems to be a common misconception.

Thank you very much for the explanations, I was very wrong. I think LLVM developers have to put this important information in more evidence.

Bye,
bearophile

bearophile wrote:
> Thanks to Reddit I have found a nice short document that lists some of the differences of C#4:
> https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv
> 
> They have added a dynamic invocation, useful if you want to implement a dynamic language (like IronPython, IronRuby, etc) on top of the dotnet. Object-C shows this is doable in a very C-like language, and the Boo language shows that in a statically typed language it can be useful to use a Duck type once in a while to reduce the "static type pressure". More info on this last concept in the Boo site.
> 
> Something that I like a lot is the named arguments, that I hope to see in D and Delight someday. They are used often in Python, and they help increase the readability of the code, sometimes even reducing mistakes.
> They have used colons:
> foo(x: 1, z: 3)
> While Python uses equal signs:
> foo(x=1, z=3)
> I think they are about equally readable.
> (I think there's a problem with named arguments, that you can solve in some ways, for example with an extra hidden bitfield argument that encodes what arguments are given and what not).
> 
> Bye,
> bearophile

It would be nice if this worked with structs as parameters as well:

struct X
{
	int a;
	int b;
}


foo(X x)
{

}

foo(x.a = 10, x.b = 20);

Janderson:
> It would be nice if this worked with structs as parameters as well:
> 
> struct X {
> 	int a;
> 	int b;
> }
> foo(X x) { }
> foo(x.a = 10, x.b = 20);

At the moment you can do:
foo(X(10, 20));

The docs say: "Struct literals are syntactically like function calls."
So if function calls gain the named arguments, then later you can probably write:
foo(X(b: 20, a: 10));

Bye,
bearophile

On Wed, 29 Oct 2008 21:09:50 -0000, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:

> In Python, in Python, in Python.  I'm pretty sick of hearing about
> Python.  D is not Python, D did not come from Python, D is not made to
> cater to Python users and is not designed for the same things that
> Python is used for.  Syntactic choices for symbols, operators, or
> keywords is a completely moot issue.  Please drop it.

In the python forums they're not this ;)

Seriously though D isn't just from C++. Its on one of the main description pages that
it borrows from Python and why not. Borrow from anywhere and everywhere if it leads to
improvements.
But yeah, lay off painting the bike-shed.

Ary Borenszweig wrote:
> Robert Fraser escribió:
>> Denis Koroskin wrote:
>>> I once had the following Color class:
>>>
>>> class Color
>>> {
>>>     this (byte alpha, byte red, byte green, byte blue) { ... }
>>> }
>>>
>>> and used it as follows:
>>>
>>> Color c = new Color(255, 0, 255, 0); // opaque green color
>>>
>>> After refactoring, alpha became last argument in ctor:
>>>
>>>     this(byte red, byte green, byte blue, byte alpha) { ... }
>>>
>>> Note that this change didn't raise any compilation error, nothing that would notify my of possible error.
>>>
>>> Needless to say that I didn't enjoy searching all the code that used Color to reorder parameters (although some artifact were nice :)
>>> It would save me quite some time if I initialized all my instances as follows:
>>>
>>> Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);
>>>
>>> Now compiler could raise an error if parameters order was changed. Even better - compiler could reorder parameters for me automatically if given that all of them are specified and no params ommited (unlike Python). This makes code more robust to refactoring.
>>
>> The first thing  I thought of when reading this is Eclipse JDT's "Change Method Signature" refactoring that will look up all the calls in your project & automatically reorder the parameters for you.
> 
> Me too. :-)

Of course I also ate a piece of that cake. ^^

I keep getting the impression that we 3 are the only people in the D NG that have used JDT extensively.
That's unfortunate because I feel most people here don't realize how much an IDE like JDT (or something comparable, like IntelliJ IDEA, but not VS) can shape and improve the development workflow (and thus have potential implications in language design).
And it's not something that can be easily understood in foresight - one really has to try it out (rich IDE functionality) for some time and even then, you might not notice it until it is *taken* from you. Fun story, that happened to me:

When I started looking for work after graduation, recruiters asked me if I had preference for working with C# or Java. I had no anti-Microsoft bias (apparently some people do, even in the workplace), so I judged both in terms of language only, and I really didn't have much of a preference then (note, this was considering C# only up to version 2.0 only). I was slightly inclined to Java, but only because I had used it more.
But months later, when I started working on a project that had a desktop client, I tried using C# (to take advantage of the WinForms designer) I was vexed as Visual Studio (C# 2005) seemed primitive in comparison. Suddenly many of the things I had taken from granted were gone, and I missed them a lot more than I expected (one example is the Ctrl-1 "Assign to Local Variable" refactoring which gradually become one of my most used refactoring, almost as much as Refactor-Rename). It was almost like going from C to BASIC (when I only knew BASIC, it didn't seem so sucky).
It has become so that now that I am searching for other job opportunities, given C# and Java roles, I am strictly only considering Java-based ones (and here in Portugal, C#/.NET has a big market share, as big, if not bigger, than Java).


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D