__traits() to get parameter details only ? ... hasMember looks up everything within

[Alexandru Ermicioi]

On Wednesday, 4 August 2021 at 22:28:53 UTC, someone wrote:
> Is that what you mean ?

Not really. I was assuming you were talking about @property 
methods, and if so you could declare such cases:

```
interface HasMutableLstrSymbolId {
  @property lstrSymbolId();
  @property lstrSymbolId(string id);
}

interface HasMutableLstrCurrencyId {
  @property lstrCurrencyId();
  @property lstrCurrencyId(string id);
}

class NyseTicker : HasMutableLstrSymbolId {
  //...
}

class NasdaqTicker : HasMutableLstrSymbolId, 
HasMutableLstrSymbolId  {
  // ...
}
```

Having this structure you would just need to check whether it 
implements right interface and then once you know it, just set 
the value. Note, that this approach won't work nicely if you have 
lots of fields to set. In this case I'd try a builder pattern, 
where you have a common builder interface which has Nasdaq and 
Nyse implementation that builds respective classes out of 
information available.

Now from the other replies it seems you want to get constructor 
arguments. Constructor itself is named __ctor internally (you'll 
see it listed as such when fetching allMembers), therefore fetch 
the constructor overload set (you need this because D allows 
method overloading, and therefore all methods in overload set 
should be checked), and then iterate over it and check what 
you're interested in. You can then use std.traits.Parameters to 
fetch a tuple of param types, or 
std.traits.ParameterIdentifierTuple for fetching parameter names. 
As other people recommended you can check std.traits 
implementation to get insight on the compiler magic they rely to 
do this.

Regarding @property methods, even if they are half baked, they 
are still useful in denoting properties that can be fetched or 
assigned to a class. It is similar to setters & getters 
convention in Java, or [set,get] functionality from C# as far as 
I'm aware. Having properties marked with @property also allows 
template code to be aware which methods are actually representing 
a property on the object.

Also, it is not really necessary to prefix the name of each class 
or interface with 'class' or 'interface', since this information 
is already baked into the type itself, and in most of the time 
may be just unnecessary noise for reading the code.