On Thursday, 31 August 2017 at 21:02:26 UTC, Jean-Louis Leroy
wrote:
On Thursday, 31 August 2017 at 20:42:36 UTC, EntangledQuanta
wrote:
On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
[...]
I was getting similar errors and simply added a
cast(size_t)[used in the indexing, as he used ulongs for
indexes rather than size_t] to all those you mention. After
that I got more errors that I can't recall now but was much
more cryptic. I did updateMethods and added the mixin but
things wern't working so I gave up. Seems like a nice idea,
although, the downside that I see is one doesn't get
encapsulation.
It's fixed now, in master and in release v1.0.0-rc.2.
I'll check it out. I don't think the last errors I was getting
were due to the sizing issues though, so is that all you fixed or
was there some other stuff related to windows?
Actually not getting encapsulation is good. With vfuncs, if you
want polymorphism you get access to private parts, need it or
not. And most of the time you neither need nor want it.
If you need polymorphism and privileged access, you should use
a vfunc but it's usually a sign of bad design, because a vfunc
is meant to be overridden. And the override won't have access
to the private parts so you may end up changing access from
private to protected and usually trouble follows.
I can imagine legitimate cases though. Fox example, the
DiagonalMatrix addition example. In that case you can write a
public final member function that performs addition using
privileged access and call that from the 2-method 'plus'.
Yeah, but one should always be allowed to shoot themselves in the
foot. You never know when you might do it. Maybe an alligator has
attached itself to your foot and is about to drag you under water?
ANother approach is to write the fvunc - or the 1-method - in
terms of the public interface. Usually it's feasible and yields
a better design.
