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 :)
Permalink
Reply
