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.

Reply via email to