My goodness, what a tangled web you weave... You're mutating an object AND using the return value at the same time and you're doing it twice, in the same expression!
Then to add insult to injury, you now propose to add an implicit conversion to the mix. An implicit conversion that, itself, has side effects. Do please feel free to try it for yourself, but you truly deserve whatever results you get from such an attempt! You're right, I truly have no idea what the relative order of execution is for the implicits and the mutations and the :: Then again, this sort of thing really shouldn't come up in a production system. If it did then I'd be asking some far more serious questions about code quality. It certainly wouldn't pass a review, and at first sight of such code I'd engage in a refactoring or two, as this is just plain Bad Design(tm) Such a mix of implicit conversions and mutability really is imperative programming at its worst, and captures EXACTLY the kind of mess that functional programming seeks to avoid. In the sort of idiomatic good design that Scala encourages: - You just don't combine mutation and returning a value, as ++ does - Wherever possible, functions should be pure. For the same input they will *always* produce the same output, so order of execution isn't relevant You are quite right in stating that astonishing behaviour can result from a truly abysmal design. But isn't that true of any programming language? On 9 August 2010 17:40, Ben Schulz <[email protected]> wrote: > On 9 Aug., 17:02, Kevin Wright <[email protected]> wrote: > > Well, Java has left-to-right evaluation, except when it doesn't > > > > x + y * z is equivalent to x.+(y.*(z)) NOT (x.+(y)).*(z) > > x() + y() * z() is still evaluated as > > invoke x > invoke y > invoke z > mul > add > > it has nothing to do with operator precedence. The following two > expressions are not equivalent: > > (++x) :: (++x :: Nil) > (++x :: Nil).::(++x) > > (Obviously Scala does not allow for the ++ operator, but I did not > want to write up a more complicated example.) > > > x :: someList is equivalent to someList.::(x) > > If both x and someList are identifiers then yes, and it should give > you pause, because that means the following: > > If someList does not have a ::-method, an implicit conversion to a > type that does is looked up. If x also needs implicit conversion for > the method to be applicable then the implicit conversion happens in > the same order for both expressions. Once *right-to-left* and once > left-to-right. That's astonishing behavior. > > > You also have this little gem in the Java spec: > > > > "The Java programming language also guarantees that every operand of an > > operator (except the conditional operators &&, ||, and ? :) appears to be > > fully evaluated before any part of the operation itself is performed." > > Yes, Java is a strict language with the exception of a few language > constructs. > > > and this one: > > > > 15.7.5 Evaluation Order for Other Expressions > > > > The order of evaluation for some expressions is not completely covered by > > these general rules, because these expressions may raise exceptional > > conditions at times that must be specified. See, specifically, the > detailed > > explanations of evaluation order for the following kinds of expressions: > > > > - class instance creation expressions > > - array creation expressions > > - method invocation expressions > > - array access expressions > > - assignments involving array components > > With the exception of array creation I'd expect the semantics for > Scala to be similar (due tue them sharing the same infrastructure) or > unspecified. > > > The rules for precedence and order of evaluation are rarely as simple as > you > > think :) > > I think I've got a pretty good handle on it, thanks. > > With kind regards > Ben > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
