|
You can make the property writeable in 2.0 - just
add setter method in the inherited class. The issue is that most of
the times you access the property, explicit typecasting is made by compiler
- causing exception if you are using "unrelated"
datatype.
One approach to solve this issue would be to
have another compiler keyword that bypasses type checking with dynamic
resolution on the variable level like
override dynamic var
dropdown;
That would obviously cause serious update to the
typecasting statements making them "quiet" - basically 1.5 behavior that is not
advertised, but available for hackers - probably would be banned by archtects
and remain unused by corporate developers.
Other well-defined approach is to seriously
reevaluate extensibility of the product and extend it with tons of interfaces.
Has been tried number of times with Java, never (to my best knowledge)
commercially successfully with front-end large scale tool. In the
end/maintenance stage, I always had to do "fine tuning" by using
Java scripting products like beanshell.
That leaves the third approach I like most. I am
glad you (presumably unconsciously due to similar problem) remembered
PowerBuilder scripting language. PB also had single inheritance and no
decorations. At a certain maturity level they decided to do strong type checking
and optimization at the expense of "scripting power tricks". The problem was
that they had significant user base at the time of the change and could not
afford to loose early adopters.
However, they solved this problem with simplicity
and pragmatism that always win the users appreciation. They allowed method call
modifier "dynamic". For simplicity I will switch PowerBuilder type ANY to
Object :
class a { function test(x:int){ return "a"}}
class b { function test(y:string){ return
"b"}}
//example of usage
var o:Object = new a(); o.dynamic test(5);o.invoke("test",
5); var o:Object = new b(); o.dynamic test("abc");o.invoke("test",
"abc");
They also made sure that events (seldom called as response to user
interaction/internal changes) are staying dynamic - no strong type checking
there - no need for endless switch/case statement typecasting the event type and
missing the new ones as the controls base is extended.
The "legacy" code was saved by trivial replace of non-compiling statements
with dynamic calls, the "core" run-time code base by using similar trick
retained higher percentage of the previous versions tested code that continued
to work. Main objective - giving application developers more "strict"
intellisense environment eliminating typos while allowing for more dynamic
coding when needed worked very well.
Hope it can be integrated in the current version of the compiler.
Thank you,
Anatole Tartakovsky
P.S.
It would be interesting to get feedback from the current Flex developers
who have production applications in 1.5 on the chances/effort of the conversion
from 1.5 to 2.0. That very well might give an indication of importance of the
language changes - it very well might be just my imagination. That of course is
only important if those applications have to be upgraded to 2.0.
Some other scripting languages are also subject for review as the
integrationsimplicity and power of those keep driving the users trends - PHP and
Phython is a good example what integration model can do to the environment by
enabling 3rd parties.
|
- Re: [flexcoders] Re: problem with cell renderer in Com... Anatole Tartakovsky
- [flexcoders] Re: problem with cell renderer in Co... george_lui
- [flexcoders] Re: problem with cell renderer i... bhaq1972
- Re: [flexcoders] Re: problem with cell re... Anatole Tartakovsky
- [flexcoders] Re: problem with cell re... bhaq1972
- Re: [flexcoders] Re: problem wit... Anatole Tartakovsky
- [flexcoders] Re: problem wit... bhaq1972
- [flexcoders] Re: problem with cell render... george_lui
- [flexcoders] Re: problem with cell renderer in Co... george_lui
- RE: [flexcoders] Re: problem with cell render... Matt Chotin
- RE: [flexcoders] Re: problem with cell renderer i... Matt Chotin
