www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - opPropDispatch

reply 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.
Apr 22 2012
next sibling parent reply 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
Apr 22 2012
next sibling parent 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
Apr 22 2012
prev sibling parent "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.
Apr 22 2012
prev sibling next sibling parent 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
Apr 22 2012
prev sibling next sibling parent "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.
Apr 22 2012
prev sibling next sibling parent 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
Apr 22 2012
prev sibling parent "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.
Apr 22 2012