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