• sclytrack (44/44) Apr 22 2012 struct Dispatcher
• David (2/42) Apr 22 2012 For now you can do it *without* @property and compile *without* -propert...
• Jonathan M Davis (8/9) Apr 22 2012 But that will not remain the case, so relying on that is not a good idea...
• Adam D. Ruppe (23/24) Apr 22 2012 Note that -property adds zero value, much like the current
• Jonathan M Davis (9/39) Apr 22 2012 Then there's a bug that needs to be fixed.
• Adam D. Ruppe (6/7) Apr 22 2012 Note: my problem is with -property, not @property.
• Jonathan M Davis (7/17) Apr 22 2012 Well, strict enforcement is how @property was designed in the first plac...
• Adam D. Ruppe (8/10) Apr 22 2012 That doesn't affect my argument at all,

sclytrack <sclytrack ars.com> writes:

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.

David <d dav1d.de> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.