> > Optimizing for read-once variable expressions just sounds dangerous to me. > I would not want to bake that into the compiler and invite people into a > trap. > > One way to find out how such a thing would work in the real world without > changing the compiler is to create a custom helper class that does > essentially the same thing. Folks can then try out using a SetOnceBinding > class and we'll see how often folks get burned by it. I was looking into > other specific binding helper classes to optimize bindings for > itemrenderers > and skins when 11/11 hit.
I think that if we're going to not accept this change proposal I think it has to be for better reasons than this. If we're worried about dangerous code that might invite people into traps then let's just kill off bindings altogether, I mean there are a tons of traps in the bindings world if you don't use them right. While we're at it, we should also kill off lambdas/anonymous functions, those are also a trap if used incorrectly. Also, too many interfaces can get confusing, lets kill those too they invite too many traps... See where I'm going with this? I think its a mistake to not want to accept changes because you're trying to save people from their own code. We will never save people from their own code, so things like bindings, while useful, will always be misused by someone that just doesn't have the experience or know better, that doesn't mean it shouldn't exist in the language/framework. All I'm saying is that if we're going to turn it down it should be on technical merit, or lack thereof, as opposed to whether it invites something bad, because there's lots of bad things that can be done and if we use that as criteria for changes then we'll never make any changes. -omar
