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

[someone]

On Thursday, 5 August 2021 at 01:47:36 UTC, Alexandru Ermicioi 
wrote:
> 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.

I'll find this very useful for other things I have in mind ... 
thanks for this one :)

> Now from the other replies it seems you want to get constructor 
> arguments.

> Constructor itself is named __ctor internally

ah ... bingo !

I oftenly see this thing __ctor in the forums but never knew what 
the hell it was. This is what I need.

> (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.

Yes, of course I am fully aware of what getters/setters are and 
thus I started using @property because I think it had some 
"special" functionality/whatever but after a month or so using 
them and seeing some comments here in the forums I assumed they 
were half-baked or even going away soon so I threw out them all. 
IIRC I think somewhere I read Ali saying there's nothing wrong 
implementing properties the old-way via functions because 
@property has nothing special about it but I can't state where I 
read what I am stating so take it with a grain of salt.

> 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.

Yes yes I know old habits die hard :)

I do name like this because I often have interfaceXXX alongside 
classXXX : interfaceXXX and this helps me keep track of what I am 
doing. I like to name as related-as-possible. I even still use 
the prefixed variable naming scheme that almost no new programmer 
use but this (at least for me) catches lots of errors on the fly 
-I rarely have a compiler error for a type-mismatch. In the end 
is what works for each-one.

Anyway I am changing the way I usually write code; I already 
switched behavior/style in many areas:

- private: public: sections instead of individually prefixing 
everything
- discarded once-and-for-all excessive cast() usage
- discarded in parameters and went back to const

Unneeded things I still do due to habit:

- explicitly initializing strings; eg: string lstrWhatever = null;
- explicitly initializing integers to 0
- explicitly checking bool's; eg: if (lbolWhatever == true) {}

Long-story-short: the more you learn the more you adapt to :)