November 06, 2003
Better to upset it earlier, than later, unless by doing it too early you end up causing multiple changes instead of just one.

Nobody is doing any mission-critical stuff in D yet anyway, so breaking code at this phase is not a big deal.  Better to get the language right, than to be backward compatible with an initial concept that turns out not to work well in practice.

IOW, don't be afraid to break stuff.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bochg5$1rtc$3@digitaldaemon.com...
>
> "Matthias Spycher" <matthias@coware.com> wrote in message news:bobmno$jge$1@digitaldaemon.com...
> > I've been lurking here for a year or more, enjoying the fact that this
> project
> > is progressing steadily. Keep up the good work, Walter and everyone
else.
>
> Thanks!
>
> > As for operator overloading, I like the naming convention, but I think
all
> names
> > should be prefixed with op, as in opCall to make it clear we are dealing
> with
> > operators. Names like add are actually quite common, e.g. in collection
> classes.
>
> You're right, I've been intending to do this, but I hate upsetting
existing
> code.


November 06, 2003
Agreed.

btw, what's IOW? :)

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bockub$2103$1@digitaldaemon.com...
> Better to upset it earlier, than later, unless by doing it too early you
end
> up causing multiple changes instead of just one.
>
> Nobody is doing any mission-critical stuff in D yet anyway, so breaking
code
> at this phase is not a big deal.  Better to get the language right, than
to
> be backward compatible with an initial concept that turns out not to work well in practice.
>
> IOW, don't be afraid to break stuff.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:bochg5$1rtc$3@digitaldaemon.com...
> >
> > "Matthias Spycher" <matthias@coware.com> wrote in message news:bobmno$jge$1@digitaldaemon.com...
> > > I've been lurking here for a year or more, enjoying the fact that this
> > project
> > > is progressing steadily. Keep up the good work, Walter and everyone
> else.
> >
> > Thanks!
> >
> > > As for operator overloading, I like the naming convention, but I think
> all
> > names
> > > should be prefixed with op, as in opCall to make it clear we are
dealing
> > with
> > > operators. Names like add are actually quite common, e.g. in
collection
> > classes.
> >
> > You're right, I've been intending to do this, but I hate upsetting
> existing
> > code.
>
>


November 06, 2003
In Other Words.  Thirded!

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:boclem$21vv$1@digitaldaemon.com...
> Agreed.
>
> btw, what's IOW? :)
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bockub$2103$1@digitaldaemon.com...
> > Better to upset it earlier, than later, unless by doing it too early you
> end
> > up causing multiple changes instead of just one.
> >
> > Nobody is doing any mission-critical stuff in D yet anyway, so breaking
> code
> > at this phase is not a big deal.  Better to get the language right, than
> to
> > be backward compatible with an initial concept that turns out not to
work
> > well in practice.
> >
> > IOW, don't be afraid to break stuff.
> >
> > Sean
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bochg5$1rtc$3@digitaldaemon.com...
> > >
> > > "Matthias Spycher" <matthias@coware.com> wrote in message news:bobmno$jge$1@digitaldaemon.com...
> > > > I've been lurking here for a year or more, enjoying the fact that
this
> > > project
> > > > is progressing steadily. Keep up the good work, Walter and everyone
> > else.
> > >
> > > Thanks!
> > >
> > > > As for operator overloading, I like the naming convention, but I
think
> > all
> > > names
> > > > should be prefixed with op, as in opCall to make it clear we are
> dealing
> > > with
> > > > operators. Names like add are actually quite common, e.g. in
> collection
> > > classes.
> > >
> > > You're right, I've been intending to do this, but I hate upsetting
> > existing
> > > code.
> >
> >
>
>


November 06, 2003
"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bockub$2103$1@digitaldaemon.com...
> Better to upset it earlier, than later, unless by doing it too early you
end
> up causing multiple changes instead of just one.
>
> Nobody is doing any mission-critical stuff in D yet anyway, so breaking
code
> at this phase is not a big deal.  Better to get the language right, than
to
> be backward compatible with an initial concept that turns out not to work well in practice.
>
> IOW, don't be afraid to break stuff.

Ok, I guess it will be in the next version. I really do hate breaking things.


November 06, 2003
Charles Sanders wrote:

> I agree on this one also, just some ideas but if not operator foo something
> like
> 
> __+=__ () { }
> __++__ () { }
> 
> A little pythonesque ?

Wouldn't this be terribly hard on the parser?

Is't __ a legal symbol today? Wouldn't the parser have to scan 2 or 3 tokens ahead in order to determine if the initial __ is part of an expression or an overloading method? That would in turn break LALR?

Granted, I never looked at the D parser so I could be just talking crap here. :-)

Elias

November 06, 2003
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bockub$2103$1@digitaldaemon.com...
> > Better to upset it earlier, than later, unless by doing it too early you
> end
> > up causing multiple changes instead of just one.
> >
> > Nobody is doing any mission-critical stuff in D yet anyway, so breaking
> code
> > at this phase is not a big deal.  Better to get the language right, than
> to
> > be backward compatible with an initial concept that turns out not to work well in practice.
> >
> > IOW, don't be afraid to break stuff.
>
> Ok, I guess it will be in the next version. I really do hate breaking things.


Please, never hesitate about this under 1.00 ;)

I guess the D users, who are supposed to be on the
losing side when this happens, would unanimously vote
for "please break our experimental code!" rather than
"please freeze little annoyances and limit our future
production code/style!".

Cheers,
Sz.


November 06, 2003
Absolutely. Break now is *always* better than crap later

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:bodgvp$a4l$1@digitaldaemon.com...
> > "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bockub$2103$1@digitaldaemon.com...
> > > Better to upset it earlier, than later, unless by doing it too early
you
> > end
> > > up causing multiple changes instead of just one.
> > >
> > > Nobody is doing any mission-critical stuff in D yet anyway, so
breaking
> > code
> > > at this phase is not a big deal.  Better to get the language right,
than
> > to
> > > be backward compatible with an initial concept that turns out not to
work
> > > well in practice.
> > >
> > > IOW, don't be afraid to break stuff.
> >
> > Ok, I guess it will be in the next version. I really do hate breaking things.
>
>
> Please, never hesitate about this under 1.00 ;)
>
> I guess the D users, who are supposed to be on the
> losing side when this happens, would unanimously vote
> for "please break our experimental code!" rather than
> "please freeze little annoyances and limit our future
> production code/style!".
>
> Cheers,
> Sz.
>
>


1 2
Next ›   Last »