Re: Digest for EUforum at topica.com, issue 6333
Chris Bensler wrote:
>
> Matt Lewis wrote:
> >
> > The problem with the assumption is that it doesn't stand up to scrutiny.
> > I can understand how it was initially made, but a bit of thought should
> > raise a red flag. You've got an assignment statement going into a sequence,
> > but you're fiddling with the sequence inside of the function (or in
> > something
> > it calls) before you actually assign it. There's not an obvious way to
> > resovle the 'race condition' of when does the subscripting happen. The
> > way it worked before wasn't documented, so while I can understand the
> > confusion when it stopped working, the bottom line is that you were relying
> > on something that was undocumented, and that isn't clear how it should
> > work anyways.
> >
> > From the manual:
> > "...do not try to modify the lhs_var in two different ways in the same
> > statement."
> >
> > That makes a lot of sense to me. You have to ask yourself, which one
> > will be final? It's now defined to be undefined, so if you rely on
> > some behavior, you might get a nasty surprise (as you already did when
> > the behavior changes).
>
> I think you are still missing the point.
> I understand how the side-effects work, and I agree about the 'proper
> programming
> practice'. The point is that the problem of side-effects is now much worse,
> for the sake of a very small improvement in speed.
> IMO execution speed is of a very low priority when weighing the viability of
> a given feature. More important to me is the speed of development and
> maintainability.
Then the $ is a huge winner. I'd take it even if it resulted in a
performance decrease, for the exact reason you just mentioned. It far
outweighs a subtle bug created though a dodgy programming technique that
has only been observed by a handful of people (I can't name any other
than you and Pete [IIRC], who I think first discovered it).
> Again, this method of thinking does not jive with me.
> Eu has a quirk that could easily be rectified, but instead the acceptable
> solution
> is to not only change how we code, but how we think about the code.
But what if you'd come at it from the other side? There should be limits
to backwards compatibility, and I'm really not in favor of adding MS-like
compatibility shims into Euphoria (read Raymond Chen's blog for lots of
examples).
> And your even suggesting that it is acceptable that we should be forced to
> dive
> into low level code so that we can resolve this quirk?
No, you missed the point. It just offers a short cut for those willing
and interested. Just another tool.
Matt
|
Not Categorized, Please Help
|
|
