flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Date Tue, 24 Apr 2012 17:47:24 GMT
> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message