"antiAlias" <fu@bar.com> wrote in message news:cg40vn$2tsi$1@digitaldaemon.com...
> If the compiler had no bugs, and no requirements, then there would be no issue. One would be inclined to agree that it's less of an issue now than
it
> was six months ago, yet Mango (for instance) is still waiting for
resolution
> on things noted months ago. It's rather likely that others are in the same boat.

What exactly is mango waiting on?

"Walter" wrote...
> What exactly is mango waiting on?

- The ongoing Interface issues (now described as Interface MI issues) originally noted in April, then again in June. Release notes for v0.99 say this is resolved, though I haven't tried it yet. Certain areas of Mango have been terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage, I'd go in and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but move it to another. Adding additional Interfaces to class declarations simply aggravated the problem, so Mango development vis-a-vis Interfaces just stopped.

- The version() operational discrepancy between Windows and linux was still
causing grief recently.

- Static constructors not invoked for inner/nested classes.

- The static-constructor ordering noted in May, June, and July. I've held off on a few things until that is resolved.

- The inability of a class to satisfy an Interface contract via its inheritance tree (noted in April). This is a design issue rather than a bug, but it places a burden on Mango clients that is totally unnecessary and, frankly, untenable. You don't really run into this until you start using Interfaces a lot. Mango is an Interface-based design so, naturally, comes-a-cropper over this all the time. You note there's a potential type-hole involved (though the hole is of a questionable nature, IMO), yet there are likely several ways to avoid said hole completely while still providing the required functionality.

- Corrupt stack when assigning 'out' arguments within a nested/inner function.


Each of these has stalled, delayed, or halted Mango development in one way or another. Sure, one just finds something else to work on; but it's hard to maintain focus when ongoing issues are not resolved for months on end.

Ok, I'll check them out.

"antiAlias" <fu@bar.com> wrote in message news:cg5gte$k4c$1@digitaldaemon.com...
> "Walter" wrote...
> > What exactly is mango waiting on?
>
> - The ongoing Interface issues (now described as Interface MI issues) originally noted in April, then again in June. Release notes for v0.99 say this is resolved, though I haven't tried it yet. Certain areas of Mango
have
> been terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage, I'd go in and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but move
it
> to another. Adding additional Interfaces to class declarations simply aggravated the problem, so Mango development vis-a-vis Interfaces just stopped.
>
> - The version() operational discrepancy between Windows and linux was
still
> causing grief recently.
>
> - Static constructors not invoked for inner/nested classes.
>
> - The static-constructor ordering noted in May, June, and July. I've held off on a few things until that is resolved.
>
> - The inability of a class to satisfy an Interface contract via its inheritance tree (noted in April). This is a design issue rather than a
bug,
> but it places a burden on Mango clients that is totally unnecessary and, frankly, untenable. You don't really run into this until you start using Interfaces a lot. Mango is an Interface-based design so, naturally, comes-a-cropper over this all the time. You note there's a potential type-hole involved (though the hole is of a questionable nature, IMO), yet there are likely several ways to avoid said hole completely while still providing the required functionality.
>
> - Corrupt stack when assigning 'out' arguments within a nested/inner function.
>
>
> Each of these has stalled, delayed, or halted Mango development in one way or another. Sure, one just finds something else to work on; but it's hard
to
> maintain focus when ongoing issues are not resolved for months on end.
>
>
>
>

Can either/both of you report on the results of resolution of all (but the trivial) issues, and provide some description of the ramifications.

For example, I definitely want to know a lot more about the class vs interface contract stuff. If/when this gets fixed, it'd be very useful to have an explanation.

"Walter" <newshound@digitalmars.com> wrote in message news:cg5lqs$n6p$1@digitaldaemon.com...
> Ok, I'll check them out.
>
> "antiAlias" <fu@bar.com> wrote in message news:cg5gte$k4c$1@digitaldaemon.com...
> > "Walter" wrote...
> > > What exactly is mango waiting on?
> >
> > - The ongoing Interface issues (now described as Interface MI issues) originally noted in April, then again in June. Release notes for v0.99 say this is resolved, though I haven't tried it yet. Certain areas of Mango
> have
> > been terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage, I'd go in and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but move
> it
> > to another. Adding additional Interfaces to class declarations simply aggravated the problem, so Mango development vis-a-vis Interfaces just stopped.
> >
> > - The version() operational discrepancy between Windows and linux was
> still
> > causing grief recently.
> >
> > - Static constructors not invoked for inner/nested classes.
> >
> > - The static-constructor ordering noted in May, June, and July. I've held off on a few things until that is resolved.
> >
> > - The inability of a class to satisfy an Interface contract via its inheritance tree (noted in April). This is a design issue rather than a
> bug,
> > but it places a burden on Mango clients that is totally unnecessary and, frankly, untenable. You don't really run into this until you start using Interfaces a lot. Mango is an Interface-based design so, naturally, comes-a-cropper over this all the time. You note there's a potential type-hole involved (though the hole is of a questionable nature, IMO), yet there are likely several ways to avoid said hole completely while still providing the required functionality.
> >
> > - Corrupt stack when assigning 'out' arguments within a nested/inner function.
> >
> >
> > Each of these has stalled, delayed, or halted Mango development in one way or another. Sure, one just finds something else to work on; but it's hard
> to
> > maintain focus when ongoing issues are not resolved for months on end.
> >
> >
> >
> >
>
>

Matthew wrote:

> Can either/both of you report on the results of resolution of all (but the trivial) issues, and provide some description of the ramifications.
> 

This showns that what is really needed here is a bug tracking software for the D compiler (bugzilla, mantis or something like that.) I wish I had a little more time to set up one (it's no difficult at all but it takes time), maybe in a month or two when things relax a little in my daywork (we're about to finish and deploy a big project to thousands of clients, you know what I mean).

An alternative might be to use the bug-tracking that's being put into place over at dsource.org ...

"Juanjo Álvarez" <juanjuxNO@SPAMyahoo.es> wrote in message news:cg62rd$u6g$2@digitaldaemon.com...
> Matthew wrote:
>
> > Can either/both of you report on the results of resolution of all (but
the
> > trivial) issues, and provide some description of the ramifications.
> >
>
> This showns that what is really needed here is a bug tracking software for the D compiler (bugzilla, mantis or something like that.) I wish I had a little more time to set up one (it's no difficult at all but it takes time), maybe in a month or two when things relax a little in my daywork (we're about to finish and deploy a big project to thousands of clients, you know what I mean).
>

"Walter" <newshound@digitalmars.com> escribió en el mensaje
news:cg4804$30v7$2@digitaldaemon.com
| I haven't really sent Matthew compilers to test, I just would send him one
| now and then to help him past a roadblock with DTL.

My bad then. But basically that's what they've been talking about.

-----------------------
Carlos Santander Bernal

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg61on$u9i$1@digitaldaemon.com...
> For example, I definitely want to know a lot more about the class vs
interface contract stuff. If/when this gets fixed,
> it'd be very useful to have an explanation.

There was a long and rather acrimonious thread about this recently on digitalmars.D.

"Walter" <newshound@digitalmars.com> wrote in message news:cg6gks$158t$2@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg61on$u9i$1@digitaldaemon.com...
> > For example, I definitely want to know a lot more about the class vs
> interface contract stuff. If/when this gets fixed,
> > it'd be very useful to have an explanation.
>
> There was a long and rather acrimonious thread about this recently on digitalmars.D.

Alas, I don't have much bandwidth left, so I thought I could do a last minute, definitive, cramming once it's all sorted. ;)

"Walter" <newshound@digitalmars.com> wrote in message news:cg6gks$158t$2@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg61on$u9i$1@digitaldaemon.com...
> > For example, I definitely want to know a lot more about the class vs
> interface contract stuff. If/when this gets fixed,
> > it'd be very useful to have an explanation.
>
> There was a long and rather acrimonious thread about this recently on digitalmars.D.
>
>

Surely there must be some mistake? I believe the name of the relevant thread was "Satisfying Interface Requirements" but, in reviewing it, I don't see any acrimony there. Perhaps there was in other, related, active threads at the same time?  That particular thread got little traction due to a typo in the example, which apparently caused a misunderstanding. This was later rectified, but then left unanswered and dangling ...

Here's the post noting said misunderstanding: news:ce24uf$b8j$1@digitaldaemon.com