www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New in C#4

reply bearophile <bearophileHUGS lycos.com> writes:
Thanks to Reddit I have found a nice short document that lists some of the

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
Oct 29 2008
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 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
Vote++ for named arguments. I've been meaning to bring this up for a while. Given that it's a pure syntactic sugar feature and therefore shouldn't cause any significant ripple effects (at least none that I'm aware of) and greatly simplifies design and use of APIs with lots of optional parameters, I think it's a no brainer.
Oct 29 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 30, 2008 at 12:18 AM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from bearophile (bearophileHUGS lycos.com)'s article
 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
Vote++ for named arguments. I've been meaning to bring this up for a while. Given that it's a pure syntactic sugar feature and therefore shouldn't cause any significant ripple effects (at least none that I'm aware of) and greatly simplifies design and use of APIs with lots of optional parameters, I think it's a no brainer.
I think it would be nice, but it has come up a few times in the past, and never got much traction. --bb
Oct 29 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 10:37 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Thanks to Reddit I have found a nice short document that lists some of the

 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.
Aw, man, they beat me to it. I always wondered if it would be cool to have a language that supported both static and dynamic programming natively. It was going to be the "cool thing" in the next language I made ;) (it probably still will!)
 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).
Or, you could enforce that named arguments must all have default values, or that they must _all_ be given when the function is called. Since it's getting resolved at compile time, no bitfield is necessary. It's the same thing as arguments with default values -- all the compiler does is it inserts the default values at the call site. Named parameters are very cool, though, and are invaluable for things like GUI APIs. Combined with structs, they can also remove the need for a separate struct literal syntax. S(x: 5, y: 10) looks pretty damn nice.
Oct 29 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:
 Since it's getting resolved at compile time, no bitfield is necessary.
When we have designed ShedSkin we have had to deal with named arguments too, including situations like: import sys def foo(a, b): return a - b def bar(b, a): return a / b fun = [foo, bar] if sys.argv[1] == "1": fun[0], fun[1] = fun[1], fun[0] print fun[0](a=5.0, b=3.0) The relative input/output: C:\>args.py 0 2.0 C:\>args.py 1 1.66666666667 Bye, bearophile
Oct 29 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 3:50 PM, bearophile <bearophileHUGS lycos.com> wrote:
 Jarrett Billingsley:
 Since it's getting resolved at compile time, no bitfield is necessary.
When we have designed ShedSkin we have had to deal with named arguments too, including situations like:
Ooh, that's icky. Well I'd argue then that in the equivalent in D: float foo(float a, float b) { return a - b; } float bar(float b, float a) { return a / b; } auto fun = [&foo, &bar]; ... fun[0](a: 5, b: 3); // error the last line would be an error only because function pointers are not the same as functions, and their parameters do not have names. Similar to how currently, a function pointer or delegate to a function that takes optional parameters cannot be called the same way as the original function. Still, "only" being able to call functions directly while using named/default parameters covers a _great_ majority of use cases. Covering the rest seems to be wasting a lot of implementation time and performance on something that most people honestly will not use that much.
Oct 29 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:
 Still, "only" being able to call functions directly while using
 named/default parameters covers a _great_ majority of use cases.
 Covering the rest seems to be wasting a lot of implementation time and
 performance on something that most people honestly will not use that
 much.
I agree that implementing part of the semantics of named arguments is better than nothing. In ShedSkin for example we haven't implemented the argument syntax ** yet (pass by dictionary, not so easy to implement in C++), the full argument pass semantics in Python is quite refined: def foo(x, y=5, *z, **w): print x, y, z, w Note that if D becomes more functional, then function pointers/delegates/closures become quite more commonly used. So you are limiting more than you think. Bye, bearophile
Oct 29 2008
prev sibling parent reply =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Hello Jarrett,

 Aw, man, they beat me to it.  I always wondered if it would be cool to
 have a language that supported both static and dynamic programming
 natively.  It was going to be the "cool thing" in the next language I
 made ;)  (it probably still will!)
Actually Boo supported the same thing before them. Their IQuakFoo interface Off course, before that there was ActionScript 3 which mixed both (though dynamic is the default).
Oct 29 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Julio César Carrascal Urquijo:
 Actually Boo supported the same thing before them. Their IQuakFoo interface 

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 ones in Boo, etc. Bye, bearophile
Oct 29 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
bearophile wrote:
 Julio César Carrascal Urquijo:
 Actually Boo supported the same thing before them. Their IQuakFoo interface 

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 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.
Oct 30 2008
parent bearophile <bearophileHUGS lycos.com> writes:
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
Oct 30 2008
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 29 Oct 2008 17:37:25 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:

 Thanks to Reddit I have found a nice short document that lists some of  

 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
I'm waiting for named arguments, too! They make could more readable and self-documenting: graphicsDevice->updateSettings(true, true, false, true); // wtf?? Compare to the following: graphicsDevice->updateSettings(fullScreen: true, verticalSync: true, enableBloom: false, fullScreenAA: true); 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.
Oct 29 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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);
 compiler could reorder parameters for me automatically if given  
 that all of them are specified and no params ommited (unlike Python).
Maybe I don't understand what you are saying, but Python too reorders arguments. Bye, bearophile
Oct 29 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 29 Oct 2008 23:28:25 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:

 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);
 compiler could reorder parameters for me automatically if given
 that all of them are specified and no params ommited (unlike Python).
Maybe I don't understand what you are saying, but Python too reorders arguments.
"unlike Python" is related to omitting parameters. Python allows that but it doesn't really fit statically typed langugages, I believe.
 Bye,
 bearophile
Oct 29 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:
"unlike Python" is related to omitting parameters. Python allows that but it
doesn't really fit statically typed langugages, I believe.<
I don't understand what you mean, in Python if you omit necessary arguments you receive an error: def foo(x, y=5): print x,y Bye, bearophile
Oct 29 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 4:28 PM, bearophile <bearophileHUGS lycos.com> wrote:
 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);
Er, what? They are exactly the same size.. Besides, = is already an expression in D. f(x = 5) has a well-defined meaning already.
Oct 29 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:

 Er, what?  They are exactly the same size..
In standard Python coding style usually in function calls with named arguments you don't put a space after the equal: foo(x=10) But I have just seen that after a comma people (like me) usually put a space: foo(x: 10) So the second line is a char longer. But I agree it's a not unimportant detail.
 Besides, = is already an expression in D.  f(x = 5) has a well-defined
 meaning already.
The following D code gives a syntax error: import std.stdio: writefln; int f(int x) { return x + 10; } void main() { writefln( f(x=5) ); } While this works, and assigns x to 5 in the main: import std.stdio: writefln; int f(int x) { return x + 10; } void main() { int x; writefln( f(x=5) ); // Output: 15 writefln(x); // Output: 5 } In Python x = 5 is never an expression (this precisely to avoid the typical bug of C code of using = instead of ==). And the named arguments don't change the value of the variable in the calling frame: x = 10 f(x=5) Overall I agree than the syntax with the colon is probably better for D. (While a syntax that I don't like much is the .. instead of : to define an array slice). Bye, bearophile
Oct 29 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 4:59 PM, bearophile <bearophileHUGS lycos.com> wrote:

 So the second line is a char longer. But I agree it's a not unimportant detail.
Double negative "not unimportant" -> "important" ? ;) I know, you just made a mistake.
 In Python x = 5 is never an expression (this precisely to avoid the typical
bug of C code of using = instead of ==).
OK.
 And the named arguments don't change the value of the variable in the calling
frame:

 x = 10
 f(x=5)

I'm not saying that named parameters would in D. Your example is precisely what I meant by "f(x = 5) already has a well-defined meaning in D." You're not telling me anything new.
 Overall I agree than the syntax with the colon is probably better for D.
 (While a syntax that I don't like much is the .. instead of : to define an
array slice).
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.
Oct 29 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
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.
Nov 04 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Oct 29 2008
parent Jesse Phillips <jessekphillips gmail.com> writes:
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.
Oct 29 2008
prev sibling parent ore-sama <spam here.lot> writes:
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);
 
Oct 30 2008
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Denis Koroskin" <2korden gmail.com> wrote in message 
news:op.ujsxznwqo7cclz proton.creatstudio.intranet...
 On Wed, 29 Oct 2008 17:37:25 +0300, bearophile <bearophileHUGS lycos.com> 
 wrote:

 Thanks to Reddit I have found a nice short document that lists some of 

 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
I'm waiting for named arguments, too! They make could more readable and self-documenting: graphicsDevice->updateSettings(true, true, false, true); // wtf?? Compare to the following: graphicsDevice->updateSettings(fullScreen: true, verticalSync: true, enableBloom: false, fullScreenAA: true);
I was just going to bring up the "series of bool params" issue. I very frequently find myself going out of my way to create trivial enums just to avoid using bool parameters. Similar to named parameters, as much as I normally dislike VB, I've long been jealous of its "optional params can be in the middle" capability. For instance: void foo(int a, char[] b, int c=0, char[] d="", int e, char[] f, bool g=false) {/*...*/} foo(17, "blah", , , 8.4, "stuff"); // <- Wow!! That makes it *enormously* easier to design APIs with optional parameters. No more mucking around with potentially-conflicting function overloads just to work around the "optional params must be last" requirement. No more conflict between the desire to organize params in a conceptually-logical order and the need to, again, put the optional params at the end. Plus, it seems like it would be fairly simple to implement. It's always seemed like a fairly obvious feature to me.
Oct 29 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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.
Oct 29 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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. :-)
Oct 30 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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 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 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 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 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
Nov 06 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Bruno Medeiros escribió:
 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 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 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 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).
I recently discovered you can do the same with Ctrl+2, L :-) Of course in D that'll be auto whatever = <your expression here>; Do here's a clear example where a language helps not being repetitive, and that kind of shortcut becomes less useful. But refactoring is an essential thing in TDD, and I think that can't be easily supported by any language without using a proper IDE. I also have the sensation we are the only guys that used JDT. In my workplace everyone feels very, very comfortable using Java; not because of the language itself, but because of Eclipse. It's amazing the speed boost you get once you get used to it. You don't have to look at external documentation files, you don't have to read someone else's code to understand what's going on. You don't need to remember lots of names, where's everything is located. But, as Bruno says, you can't really feel it unless you try it.
Nov 06 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:gf03qh$23sg$1 digitalmars.com...
 Bruno Medeiros escribió:
 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 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 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 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).
I recently discovered you can do the same with Ctrl+2, L :-) Of course in D that'll be auto whatever = <your expression here>; Do here's a clear example where a language helps not being repetitive, and that kind of shortcut becomes less useful. But refactoring is an essential thing in TDD, and I think that can't be easily supported by any language without using a proper IDE. I also have the sensation we are the only guys that used JDT. In my workplace everyone feels very, very comfortable using Java; not because of the language itself, but because of Eclipse. It's amazing the speed boost you get once you get used to it. You don't have to look at external documentation files, you don't have to read someone else's code to understand what's going on. You don't need to remember lots of names, where's everything is located. But, as Bruno says, you can't really feel it unless you try it.
I used Eclipse constantly back when I was working with Java (before I from version 5 through the early .NET versions. But ever since leaving Java, I've been finding myself deliberately avoiding Eclipse just because I'd much rather use an IDE that's responsive (and not so heavly Java-centric) than one that has a few extra bells and whistles. Don't get me wrong, I love IDE bells and whistles (that's why I used to be such a Visual Studio fan, and used Eclipse when I switched to Java), but when trying to interact with the IDE starts to feel like running through knee-deep molasses, as it frequently does with Eclipse, it's just not worth it to me.
Nov 06 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Nick Sabalausky wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:gf03qh$23sg$1 digitalmars.com...
 Bruno Medeiros escribió:
 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 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 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 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).
I recently discovered you can do the same with Ctrl+2, L :-) Of course in D that'll be auto whatever = <your expression here>; Do here's a clear example where a language helps not being repetitive, and that kind of shortcut becomes less useful. But refactoring is an essential thing in TDD, and I think that can't be easily supported by any language without using a proper IDE. I also have the sensation we are the only guys that used JDT. In my workplace everyone feels very, very comfortable using Java; not because of the language itself, but because of Eclipse. It's amazing the speed boost you get once you get used to it. You don't have to look at external documentation files, you don't have to read someone else's code to understand what's going on. You don't need to remember lots of names, where's everything is located. But, as Bruno says, you can't really feel it unless you try it.
I used Eclipse constantly back when I was working with Java (before I from version 5 through the early .NET versions. But ever since leaving Java, I've been finding myself deliberately avoiding Eclipse just because I'd much rather use an IDE that's responsive (and not so heavly Java-centric) than one that has a few extra bells and whistles. Don't get me wrong, I love IDE bells and whistles (that's why I used to be such a Visual Studio fan, and used Eclipse when I switched to Java), but when trying to interact with the IDE starts to feel like running through knee-deep molasses, as it frequently does with Eclipse, it's just not worth it to me.
Well, I'm not sure if that was your case, but if we are talking web development (something I did in my job), then the Java web development component of Eclipse (WTP, which extends JDT), is noticeably slow and somewhat unstable on several parts. It really isn't up to par to basic JDT, which is much more mature, although WTP has been improving lately. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 07 2008
parent "Nick Sabalausky" <a a.a> writes:
"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:gf1tci$2s5o$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:gf03qh$23sg$1 digitalmars.com...
 Bruno Medeiros escribió:
 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 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 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 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).
I recently discovered you can do the same with Ctrl+2, L :-) Of course in D that'll be auto whatever = <your expression here>; Do here's a clear example where a language helps not being repetitive, and that kind of shortcut becomes less useful. But refactoring is an essential thing in TDD, and I think that can't be easily supported by any language without using a proper IDE. I also have the sensation we are the only guys that used JDT. In my workplace everyone feels very, very comfortable using Java; not because of the language itself, but because of Eclipse. It's amazing the speed boost you get once you get used to it. You don't have to look at external documentation files, you don't have to read someone else's code to understand what's going on. You don't need to remember lots of names, where's everything is located. But, as Bruno says, you can't really feel it unless you try it.
I used Eclipse constantly back when I was working with Java (before I fan from version 5 through the early .NET versions. But ever since leaving Java, I've been finding myself deliberately avoiding Eclipse just because I'd much rather use an IDE that's responsive (and not so heavly Java-centric) than one that has a few extra bells and whistles. Don't get me wrong, I love IDE bells and whistles (that's why I used to be such a Visual Studio fan, and used Eclipse when I switched to Java), but when trying to interact with the IDE starts to feel like running through knee-deep molasses, as it frequently does with Eclipse, it's just not worth it to me.
Well, I'm not sure if that was your case, but if we are talking web development (something I did in my job), then the Java web development component of Eclipse (WTP, which extends JDT), is noticeably slow and somewhat unstable on several parts. It really isn't up to par to basic JDT, which is much more mature, although WTP has been improving lately. I
I've done a lot of web work, but none of the Java work I've done was web (at least not server-side anyway). The was just normal ordinary Java applications, command-line and GUI, and the occasional embedded applet. The .NET versions of Visual Studio have, unfortunately, been getting increasingly boated, but in my experience, Eclipse is still more boated. Although, I can't say much about Visual Studio's web stuff. The last time I used Visual Studio for web, it was still called InterDev.
Nov 07 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ary Borenszweig wrote:
 Bruno Medeiros escribió:
 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 anti-Microsoft bias (apparently some people do, even in the workplace), so I judged both in terms of language only, and I really 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 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).
I recently discovered you can do the same with Ctrl+2, L :-) Of course in D that'll be auto whatever = <your expression here>; Do here's a clear example where a language helps not being repetitive, and that kind of shortcut becomes less useful. But refactoring is an essential thing in TDD, and I think that can't be easily supported by any language without using a proper IDE. I also have the sensation we are the only guys that used JDT. In my workplace everyone feels very, very comfortable using Java; not because of the language itself, but because of Eclipse. It's amazing the speed boost you get once you get used to it. You don't have to look at external documentation files, you don't have to read someone else's code to understand what's going on. You don't need to remember lots of names, where's everything is located.
"you don't have to read someone else's code to understand what's going on." - Hum, I agree with the rest of what you said, but not necessarily on this one. In fact I do a lot of "browsing" with Eclipse (Ctrl-click, Open Type, etc.), in order to read other's code. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 07 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Bruno Medeiros wrote:
 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).
I haven't used JDT very much -- I can't stand the standard library in Java, so I try to avoid it. I've used Visual Studio with Resharper. From what I've seen, Resharper is much better than JDT. It might just be a matter of default configurations, but that's still a strong advantage. Still, Resharper costs $250 on top of the cost of Visual Studio, and it won't work with the free versions of VS. faster when working with Resharper. Enough so that if Resharper is not functioning, getting it in working order is my top priority.
Nov 07 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ge9sf5$1vdc$1 digitalmars.com...
 Thanks to Reddit I have found a nice short document that lists some of the 

 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
I'm dissapointed...but not surprised. Looks like the templates are still gimped: I don't see anything about an IArithmetic or operator constraints. I'm also dissapointed with the focus on dynamic programming as I've really never seen much need for such a thing in a static language (or in any language, IMO). Most people experienced with static typing are probably well aware of the pitfalls dynamic typing introduces, so I won't point them out. And as far as I've seen, the only benefits that can't already be achieved just fine through templates or boxing are just incredibly trivial things like not creating an extra variable to hold the string equivilant of one of your ints.
Oct 29 2008
parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 5:14 PM, Nick Sabalausky <a a.a> wrote:
 And as far as I've seen, the only benefits that can't already be achieved
 just fine through templates or boxing are just incredibly trivial things
 like not creating an extra variable to hold the string equivilant of one of
 your ints.
Er - "holding the string equivalent of an int"? Which are you arguing against, then: dynamic typing or weak typing? They are two separate axes of typing systems that are often erroneously conflated.. If you're arguing against weak typing - that is, providing loopholes in the typing system by means of implicit conversions that exist for no other purpose than convenience - I am with you 100%. Weak typing is an absolute abomination that does not deserve to belong in any language that is to be used as more than a toy. But if you're arguing against dynamic typing, or more generally dynamic object manipulation, I'm not sure I'd agree. Dynamic typing does have some very nice use cases - RPC (without having to dynamically generate and compile statically-typed code), database interaction, GUIs (see obj-c), interaction with other dynamically-typed languages, etc. Having either dynamic or static typing just makes emulating the other a pain or impossible. Having both gives you the best of both worlds.
Oct 29 2008
prev sibling next sibling parent digited <digited yandex.ru> writes:
+1 for named arguments
Oct 29 2008
prev sibling next sibling parent reply Janderson <ask me.com> writes:
bearophile wrote:
 Thanks to Reddit I have found a nice short document that lists some of the

 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);
Oct 30 2008
parent bearophile <bearophileHUGS lycos.com> writes:
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
Oct 30 2008
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
bearophile wrote:
 Thanks to Reddit I have found a nice short document that lists some of the

 https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv
 
Hum, interesting how they tackled the covariance/contravariance problem in generics parameters. It's not as powerful as Java's generics (in Java you can have covariance and contravariance in a List-like interface), but it's also quite simpler, so it's an interesting compromise. Hum, I wonder if we can implement a system anywhere like Java's generics in D. Could be possible, when we have opImplicitCast.
 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.
 
I'm usually quite a fan of hard, disciplined, static typing, but it's an interesting idea nonetheless. Wonder if it would be worth putting into D. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 07 2008
prev sibling parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
The nestable object literal syntax obsoletes some cases where constructutors 
were used before, and where named arguments would be used, but clearly not 
all (deterministic initialization) - it can be used to initialize properties 
via new Person() { First = "Bob", Last = "Smith" }; I can't remember the 
exact syntax.

- Bent

"bearophile" <bearophileHUGS lycos.com> skrev i meddelelsen 
news:ge9sf5$1vdc$1 digitalmars.com...
 Thanks to Reddit I have found a nice short document that lists some of the 

 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 
Nov 10 2008