On 2014-06-13 20:16, H. S. Teoh via Digitalmars-d wrote:
I think this is starting to show itself as an anti-pattern, or at least,
one of those obscure dark corners of D infested with complex
interactions between unexpected features and possible compiler quirks.
Probably the best thing to do is t
On 2014-06-13 16:39:04 +, H. S. Teoh via Digitalmars-d said:
Basically, once the derived class overrides the property setter, the
(un-overridden) base class getter somehow becomes shadowed as well, and
references to .prop will cause a compile error saying that Derived.prop
can't be called w
On Friday, 13 June 2014 at 18:18:21 UTC, H. S. Teoh via
Digitalmars-d wrote:
Aliasing super.prop to .prop in the derived class didn't work,
in fact,
it made things worse; now I have an infinite loop because all
occurrences of .prop get redirected back to the base class
(including
the setter), a
Odd, I thought you weren't able to override only a single
overload of a property? I might be imagining things, but I recall
at least previously that you had to override all getters/setters
if you wanted to override any for a property.
Personally I think D made a significant mistake in the way
On Fri, Jun 13, 2014 at 10:53:38AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Fri, 13 Jun 2014 09:39:04 -0700
> "H. S. Teoh via Digitalmars-d" wrote:
>
> > I'm not sure if this is a bug, or an anti-pattern, or what, but I ran
> > into this issue yesterday:
> >
> > class Base {
> >
On Fri, 13 Jun 2014 09:39:04 -0700
"H. S. Teoh via Digitalmars-d" wrote:
> I'm not sure if this is a bug, or an anti-pattern, or what, but I ran
> into this issue yesterday:
>
> class Base {
> int propImpl;
> final @property int prop() { return propImpl; }
> @property void pro
I'm not sure if this is a bug, or an anti-pattern, or what, but I ran
into this issue yesterday:
class Base {
int propImpl;
final @property int prop() { return propImpl; }
@property void prop(int newVal) { propImpl = newVal; }
