www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Filter for opDispatch?

reply frame <frame86 live.com> writes:
When using opDispatch()

- how can I tell the compiler that I do not want to handle some 
calls? Some code is testing for range methods (empty, front, 
popFront) and I don't know where and which side effects it causes.

- how can I dismiss calls from __traits(compiles)?
May 14 2021
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 14 May 2021 at 22:39:29 UTC, frame wrote:

 - how can I tell the compiler that I do not want to handle some 
 calls?


Put a template constraint on it. `void opDispatch(string s)() 
if(s == "whatever")` or minimally like `if(s != "popFront")`

This kind of thing is why I always put opDispatch on a helper 
thing now though, and still do the != "popFront" just to stop the 
ducktypers.
May 14 2021
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
On Friday, 14 May 2021 at 22:39:29 UTC, frame wrote:

 When using opDispatch()

 - how can I tell the compiler that I do not want to handle some 
 calls? Some code is testing for range methods (empty, front, 
 popFront) and I don't know where and which side effects it 
 causes.


Use a template constraint. For example:

     auto opDispatch(string method, Args...)(Args args)
         if (shouldHandle!method)
     {
         // ...
     }

...where `shouldHandle` checks the method name and returns `true` 
if you want to handle it, or `false` if you don't.


 - how can I dismiss calls from __traits(compiles)?


You can't.
May 14 2021
prev sibling parent reply frame <frame86 live.com> writes:
On Friday, 14 May 2021 at 22:39:29 UTC, frame wrote:

 When using opDispatch()


Thanks! I stumbled around with static asserts and mixins... 
totally forgot about the constraints but they will to the trick.
May 14 2021
parent reply frame <frame86 live.com> writes:
On Friday, 14 May 2021 at 23:02:22 UTC, frame wrote:


 Thanks! I stumbled around with static asserts and mixins... 
 totally forgot about the constraints but they will to the trick.


Now I run into the error

"class Foo member s is not accessible"
"template instance Base.opDispatch!("s", int, Foo) error 
instantiating"

and I have no clue why.

I swear the original code is just simple as that and 
satisfyDispatch works fine (there is no problem if I change s to 
a simple field).

```d
abstract class Base {
   void opDispatch(string property, S, this T)(auto ref S v) // if 
(satisfyDispatch!(T, property))
   {
      __traits(getMember, cast(T) this, property) = v; // error 
reported here
   }

   auto opDispatch(string property, this T)() // if 
(satisfyDispatch!(T, property))
   {
     return __traits(getMember, cast(T) this, property);
   }
}

// other module
class Foo : Base {
   protected:
     int _s;

     // int s; // would work

     void s(int v) {
         _s = v;
     }

     int s() {
         return _s;
     }
}

// called from a method like this:
void updateValue(T, V)(V value, Object object) {
    (cast(T) object).opDispatch!(property)(value);
}

```

I first thought the compiler does a recursive call on 
__traits(getMember) but it has no problems with this simple code 
above.
May 15 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 15 May 2021 at 23:41:19 UTC, frame wrote:

 On Friday, 14 May 2021 at 23:02:22 UTC, frame wrote:


 Thanks! I stumbled around with static asserts and mixins... 
 totally forgot about the constraints but they will to the 
 trick.


 Now I run into the error

 "class Foo member s is not accessible"
 "template instance Base.opDispatch!("s", int, Foo) error 
 instantiating"

 and I have no clue why.


Does it work if you remove `protected` from the derived class?
May 15 2021
parent reply frame <frame86 live.com> writes:
On Saturday, 15 May 2021 at 23:59:49 UTC, Paul Backus wrote:

 On Saturday, 15 May 2021 at 23:41:19 UTC, frame wrote:

 On Friday, 14 May 2021 at 23:02:22 UTC, frame wrote:


 Thanks! I stumbled around with static asserts and mixins... 
 totally forgot about the constraints but they will to the 
 trick.


 Now I run into the error

 "class Foo member s is not accessible"
 "template instance Base.opDispatch!("s", int, Foo) error 
 instantiating"

 and I have no clue why.


 Does it work if you remove `protected` from the derived class?


Yes, but why should the derived class not have access to it?
May 15 2021
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 16 May 2021 at 00:04:39 UTC, frame wrote:

 On Saturday, 15 May 2021 at 23:59:49 UTC, Paul Backus wrote:

 Does it work if you remove `protected` from the derived class?


 Yes, but why should the derived class not have access to it?


Possibly because you're accessing it from an `opDispatch` method 
defined in the base class. I'm not 100% sure how `protected` 
works in that case, but just from reading the spec it seems like 
it could be an issue.
May 15 2021
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 16 May 2021 at 00:04:39 UTC, frame wrote:


 Yes, but why should the derived class not have access to it?


I don't think that's your problem. From the template docs:


 _TemplateInstances_ are always instantiated in the scope of 
 where the _TemplateDeclaration_ is declared...


Your `opDispatch` templates are instantiated in the scope of 
`Base`, from which `_s` is not accessible when it's protected.
May 15 2021
parent reply frame <frame86 live.com> writes:
On Sunday, 16 May 2021 at 03:19:04 UTC, Mike Parker wrote:

 On Sunday, 16 May 2021 at 00:04:39 UTC, frame wrote:


 Yes, but why should the derived class not have access to it?


 I don't think that's your problem. From the template docs:


 _TemplateInstances_ are always instantiated in the scope of 
 where the _TemplateDeclaration_ is declared...


 Your `opDispatch` templates are instantiated in the scope of 
 `Base`, from which `_s` is not accessible when it's protected.


Indeed, the error goes away if each derived class has its own 
implementation.

But the same with fields work? They are also protected.
May 15 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 16 May 2021 at 04:07:15 UTC, frame wrote:


 But the same with fields work? They are also protected.


I'm not sure what you mean by "fields" here.
May 15 2021
parent frame <frame86 live.com> writes:
On Sunday, 16 May 2021 at 04:38:52 UTC, Mike Parker wrote:

 On Sunday, 16 May 2021 at 04:07:15 UTC, frame wrote:


 But the same with fields work? They are also protected.


 I'm not sure what you mean by "fields" here.


```d
protected:

// inaccessible
/*
void s(int v) {
   _s = v;
}

int s() {
   return _s;
}*/

// no problem here?
int s;
```
May 15 2021