Properties: problems

[Chad J]

John C wrote:
> Here's a couple of annoying problems I encounter quite often with D's
> properties. Would having some form of property syntax fix them?
> 
> 1) Array extensions:
> 
>   class Person {
> 
>     string name_;
> 
>     string name() {
>       return name_;
>     }
> 
>   }
> 
>   auto person = getPerson();
>   auto firstAndLast = person.name.split(' ');
> 
> The above line currently requires parentheses after 'name' to compile.
> 

This one is weird.  After defining getPerson() I was able to rewrite the
last line into this and make it compile:

	auto firstAndLast = split(person.name," ");

Note that you need qoutes, not just ' '.
But even

	auto firstAndLast = person.name.split(" ");

does not compile.
main2.d(36): Error: function expected before (), not
split(person.name()) of type immutable(char)[][]

This is probably a compiler bug.

I don't think property syntax is truly necessary for this example.  You
are fortunate enough to be using strings, which are passed by reference.

> 2) Indexing:
> 
>   struct Map(K, V) {
> 
>     void opIndexAssign(V value, K key) { ... }
>     V opIndex(K key) { ... }
> 
>   }
> 
>   class WebClient {
> 
>     private Map!(string, string) headers_;
> 
>     Map!(string, string) headers() {
>       return headers_;
>     }
> 
>   }
> 
>   auto client = new WebClient();
>   client.headers["User-Agent"] = "MyWebClient";
> 
> The compiler says client.headers() is not an lvalue (adding 'ref' in D2
> changes nothing).

This is nearly the same thing as the "a.b.c = 3;" example given in the
"a.b.c = 3;" thread.  The .b is your .headers.  It's slightly more
forgiving though, since you are calling a function on the returned
struct and not accessing a field.  The setter never needs to be called
in your example.

I'll use the compiler's rewritting technique to show you what it looks like:

client.headers["User-Agent"] = "MyWebClient";
client.headers.opIndexAssign("User-Agent","MyWebClient");
client.headers().opIndexAssign("User-Agent","MyWebClient");

client.headers() creates a /new/ Map!(...) struct, so the opIndexAssign
will not be called on the one you want it to be called on.

Adding 'ref' should change that.  That sounds like a bug.

In this specific example, property syntax is not truly necessary.  That
ref returns were added should make this doable.