struct Dispatcher
{
	@property
	void opDispatch(string name)(string val)
	{
		writeln(val);
	}
	
	@property
	string opDispatch(string name)()
	{
		return "getter";
	}
	
	void opDispatch(string name)()
	{
		writeln(name);
	}
}


I can't seem to make a "dispatcher" that supports both the normal method syntax and the property syntax simultaneously. Is this going to change in the future?

And if so, how will this be done?

Like this?

struct Dispatcher
{
	@property
	void opPropDispatch(string name)(string val)
	{
		writeln(val);
	}
	
	@property
	string opPropDispatch(string name)()
	{
		return "getter";
	}
	
	void opDispatch(string name)()
	{
		writeln(name);
	}
}

I've got absolutely no clue.

Am 22.04.2012 22:11, schrieb sclytrack:
>
>
> struct Dispatcher
> {
> @property
> void opDispatch(string name)(string val)
> {
> writeln(val);
> }
>
> @property
> string opDispatch(string name)()
> {
> return "getter";
> }
>
> void opDispatch(string name)()
> {
> writeln(name);
> }
> }
>
>
> I can't seem to make a "dispatcher" that supports both the normal method
> syntax and the property syntax simultaneously. Is this going to change
> in the future?
>
> And if so, how will this be done?
>
> Like this?
>
> struct Dispatcher
> {
> @property
> void opPropDispatch(string name)(string val)
> {
> writeln(val);
> }
>
> @property
> string opPropDispatch(string name)()
> {
> return "getter";
> }
>
> void opDispatch(string name)()
> {
> writeln(name);
> }
> }
>
> I've got absolutely no clue.
>

For now you can do it *without* @property and compile *without* -property

On Sunday, April 22, 2012 22:30:01 David wrote:
> For now you can do it *without* @property and compile *without* -property

But that will not remain the case, so relying on that is not a good idea. Eventually -property will be the normal behavior.

As for opPropDispatch, I don't think that it's something that's been brought up before. So no, there are no plans for it. I don't know what the odds of being able to add something like that are though. That would be better discussed in the main newsgroup.

- Jonathan M Davis

On Sunday, 22 April 2012 at 22:36:12 UTC, Jonathan M Davis wrote:
> Eventually -property will be the normal behavior.

Note that -property adds zero value, much like the current
implementation of @property, which fails to disambiguate
cases:

==
import std.stdio;

alias void delegate() callable;

class Test {
	@property callable a() { return { writeln("hello"); }; }
}

void main() {
	auto t = new Test();
	t.a(); // does NOT say hello
        t.a()(); // this does
}
==

I thought this case was the WHOLE POINT of adding
@property, and it is still wrong.

Note that this should work just fine without the
pointless baggage that is -property, since the
@property gives the necessary info to disambiguate
it. But, apparently, the compiler ignores it all,
with or without the switch.

On Monday, April 23, 2012 01:01:48 Adam D. Ruppe wrote:
> On Sunday, 22 April 2012 at 22:36:12 UTC, Jonathan M Davis wrote:
> > Eventually -property will be the normal behavior.
> 
> Note that -property adds zero value, much like the current implementation of @property, which fails to disambiguate cases:
> 
> ==
> import std.stdio;
> 
> alias void delegate() callable;
> 
> class Test {
> 	@property callable a() { return { writeln("hello"); }; }
> }
> 
> void main() {
> 	auto t = new Test();
> 	t.a(); // does NOT say hello
>          t.a()(); // this does
> }
> ==
> 
> I thought this case was the WHOLE POINT of adding @property, and it is still wrong.

Then there's a bug that needs to be fixed.

http://d.puremagic.com/issues/show_bug.cgi?id=7970

> Note that this should work just fine without the
> pointless baggage that is -property, since the
> @property gives the necessary info to disambiguate
> it. But, apparently, the compiler ignores it all,
> with or without the switch.

Well, I completely disagree with you on @property. I think that definitely adds value and that we're far better off having it - as long as it's properly enforced. But we've debated this before, and from what I can tell, neither of us is going to convince the other. @property has proven to be one of the more devisive feature changes in D.

- Jonathan M Davis

On Sunday, 22 April 2012 at 23:21:57 UTC, Jonathan M Davis wrote:
> Well, I completely disagree with you on @property.

Note: my problem is with -property, not @property.

If @property was correctly implemented, it'd serve
a very nice purpose. The reason I'm aware of the
bug is this is something I've wanted to use before.

-property is another story entirely.

On Monday, April 23, 2012 01:39:44 Adam D. Ruppe wrote:
> On Sunday, 22 April 2012 at 23:21:57 UTC, Jonathan M Davis wrote:
> > Well, I completely disagree with you on @property.
> 
> Note: my problem is with -property, not @property.
> 
> If @property was correctly implemented, it'd serve
> a very nice purpose. The reason I'm aware of the
> bug is this is something I've wanted to use before.
> 
> -property is another story entirely.

Well, strict enforcement is how @property was designed in the first place (and is how it's described in TDPL). It just hasn't been enabled as the normal behavior yet in order to give people a chance to fix their code first (and to give the compiler a chance to iron out its property-enforcement bugs). So, you're arguing for a partial implementation of @property.

- Jonathan M Davis

On Sunday, 22 April 2012 at 23:54:17 UTC, Jonathan M Davis wrote:
> Well, strict enforcement is how @property was designed in the first place (and is how it's described in TDPL).

That doesn't affect my argument at all,

People actually use the implementation as it is, which
is a superset of the TDPL definition.

Enforcing that definition breaks code and, if anything,
adds only minor maintenance benefits.

It'd be easier to strike the word "must" from future
printings of the book than to fix all D code everywhere.