On Thu, Jul 23, 2009 at 11:49:29PM +0100, Tom S wrote:
> It's not much worse, but it's not everything that's to tuples. Here's one more example:
> 
> > int a, b;
> 
> ----
> 
> > a, b = 2, 3;


Why would you ever want to do that when you have:

a = 2;
b = 3;


I see people ask why would you ever want the existing comma operator, when you can just separate it into two lines, and the replacement use could also just be separated into two lines.

The swap function I've seen tossed around could just be swap(x,y) instead of y,x = x,y too. A fancier rearrange could be done with a template, so:

(x, y, z) = (z, y, z)

becomes:

rearrange(x, y, z,   z, y, x);




I could see a function returning it as being potentially useful for the x,y case:

Tuple!(int, int) getPoint() { return tuple(x, y); }
...

x, y = getPoint();


But, a better way to do this would be:

Tuple!(int, "x", int, "y") getPoint() { return tuple(x, y); }
...

auto p = getPoint();
// work with p.x and p.y

It is two brief lines longer to copy them to a local x and y if you want to.


-- 
Adam D. Ruppe
http://arsdnet.net

On Thu, Jul 23, 2009 at 05:53:35PM -0700, Bill Baxter wrote:
> Uh, yes.  Yes it is.
> But I have to say I'm always amazed what clutter some people are
> apparently willing to put up with when I look at just about any page
> of MSDN.

And I'm amazed at the illegibility some people are apparently willing to put up with whenever I look at just about any scripting language code. (Or regular expressions, my God!)

I certainly wouldn't go into Java territory for bondage and discipline, but some amount of verbosity helps keep me sane.


> 
> --bb

-- 
Adam D. Ruppe
http://arsdnet.net

Walter Bright wrote:
> Ary Borenszweig wrote:
>> Walter Bright wrote:
>>> Michiel Helvensteijn wrote:
>>>> * No control over their use by class designer: ANY member function
>>>> with one
>>>> or zero parameters may be called using 'property syntax'. This is not a
>>>> good thing.
>>>
>>> Why not? Seriously, what is the semantic difference?
>>
>> Semantic difference: a property doesn't have *visible* side effects. If you invoke it one hundred times, it should always return the same thing. And nothing else in your program should change. So it's kind of like pure functions.
>>
>> I say "visible" because you might want to implement a property lazily. But the logic remains inside your class and it's visible in the outside world.
> 
> Ok, but not having visible side effects is just a convention, one which is apparently not enforced by languages with special property syntax.
> 
> A pure function, however, can be statically guaranteed to have no side effects. So IDEs, etc., can regard as 'properties' any such methods which take no arguments.

That's true, but you haven't addressed the other side of it: property setters.

Let me give you an example of where I think a few people are trying to come from.  In VB6, you could create custom ActiveX controls.  In the code for it, you could declare properties with getters and setters.

The nice thing was that because the IDE could tell the difference between functions and properties, it could display these properties automatically in the property sheet for each control.

With D, you would need to explicitly state which methods are properties manually somehow; dunno how you would, though.  Especially when you consider subclassing and mixins.

On Thu, 23 Jul 2009 21:22:03 -0400, Adam D. Ruppe wrote:

> 
> I could see a function returning it as being potentially useful for the x,y case:
> 
> Tuple!(int, int) getPoint() { return tuple(x, y); } ...
> 
> x, y = getPoint();
> 
> 
> But, a better way to do this would be:
> 
> Tuple!(int, "x", int, "y") getPoint() { return tuple(x, y); } ...
> 
> auto p = getPoint();
> // work with p.x and p.y
> 
> It is two brief lines longer to copy them to a local x and y if you want to.

Thanks for the tutorial, expect to see it on Wiki4D within a year :D

Walter Bright wrote:
> Rainer Deyke wrote:
>> Syntactic ambiguity.  Confusion between an instance of a class and a reference to that instance.
> 
> I was initially thrown by this when I started some Java programming. But it soon became clear this was an advantage, and I came to prefer it.

I like it in Python, where all variables are references.  Java is similar to Python in this regard, although the existence of primitive value types complicates the situation somewhat.

I don't like it in D, where reference types and value types coexist.  I especially don't like it in templates in D, where it may not be clear if you're dealing with a reference type or a value type until instantiation.


-- 
Rainer Deyke - rainerd@eldwood.com

On Thu, 23 Jul 2009 22:06:23 +0200, Knud Soerensen wrote:

> Walter Bright wrote:
> 
>>> I know the real focus for D system programing and the C++ people.
>>>
>>> I think one of D's strongest points for people to make the switch is build in unit testing. (at least this is the strongest point for me) But the very simple implementation of unit testing in D nearly ruin the advantage it gives. (see suggestion from the wishlist below)
>> 
>> Even at its very simple support, it's a huge win. It raises the bar on what is minimally acceptable, and has been responsible for a big improvement in the quality of Phobos.
> Yes, but the chose is not about unit test or no unit test.
> 
> It is between using D with its very simple unit test framework or C++/java/etc with a very good unit testing framework.
> 
> I think that D should provide a framework on the same level or maybe just make the best unit testing framework on the planet.

But those languages don't have Unit testing. There are libraries that let you do Unit testing in those languages, but it isn't the language. Hence the creation of DUnit.

On Fri, Jul 24, 2009 at 01:38:30AM +0000, Jesse Phillips wrote:
> Thanks for the tutorial, expect to see it on Wiki4D within a year :D

This actually doesn't /quite/ work, since the tuple returned by tuple() has unnamed fields, which is a different type than the one with named fields.

Gah.

This works though:

auto getPoint() { return Tuple!(int, "x", int, "y")(5, 2); }

That's getting a wee bit ugly even for my likes, but is the best way for correctness and ease of use on the calling end. Or

Tuple!(int, int) getPoint() { return tuple(5,2); }

That works, but then you have to address the return value as:

auto p = getPoint();
p.field[0] == 5
p.field[1] == 2


Still, easy enough to say:

auto x = p.field[0]; auto y = p.field[1];
x == 5
y == 2



-- 
Adam D. Ruppe
http://arsdnet.net

On Thu, 23 Jul 2009 22:56:44 -0400, Adam D. Ruppe wrote:

> On Fri, Jul 24, 2009 at 01:38:30AM +0000, Jesse Phillips wrote:
>> Thanks for the tutorial, expect to see it on Wiki4D within a year :D
> 
> This actually doesn't /quite/ work, since the tuple returned by tuple() has unnamed fields, which is a different type than the one with named fields.
> 
> Gah.
> 
> This works though:
> 
> auto getPoint() { return Tuple!(int, "x", int, "y")(5, 2); }
> 
> That's getting a wee bit ugly even for my likes, but is the best way for correctness and ease of use on the calling end. Or
> 
> Tuple!(int, int) getPoint() { return tuple(5,2); }
> 
> That works, but then you have to address the return value as:
> 
> auto p = getPoint();
> p.field[0] == 5
> p.field[1] == 2
> 
> 
> Still, easy enough to say:
> 
> auto x = p.field[0]; auto y = p.field[1]; x == 5
> y == 2

Thanks, truth be told I don't know why that first one works. But the second looks completely reasonable.

Adam D. Ruppe wrote:
> (...) It is two brief lines longer to copy them to a local x and y if you want to.

Remember delegate literals? They were just a few more tokens, but it wasn't until the shorthand syntax was introduced that everyone started using them. I mean, how hard is it to type the extra 'delegate' and perhaps a return type after it...


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

"Lutger" <lutger.blijdestijn@gmail.com> wrote in message news:h4agu7$2cme$1@digitalmars.com...
>
> There have been a lot of discussions on this topic in the past but I can't
> recall any conclusions. Perhaps some brave soul would dare to write a DIP
> on
> properties?
>

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4

I'm making a post for this over on D.announce...