Om: not quite. There is one implied default namespace for any XML document,
it's something with w3c in the URI, it's the namespace where 'lang'
attribute goes for example. So, what I was saying in my first response is
that Flex could've had added one default namespace too, for example for
built-in classes, such as int, Number, String etc. To be honest, I could
never understand what do these do under mx or spark namespaces. It would be
also informative and good from the educational standpoint to have flash.*
classes in a special namespace, because these are also sorts of built-ins.
And then all the rest to be whatever people want them to be.
Gordon. Oh, OK, your previous answer just sounded odd without this
explanation.
Duane, probably not a good example, because this is taken care of by DTDs
and such: the bar inside bar would be distinct from bar inside foo by the
fact it's inside bar. But these rules' complexity rises in geometrical
progression, so they are not useful for non-trivial XML documents. But, XML
is just a bad format for most purposes it's been used in 21'st century, so
these aren't news.
I think that it's not possible today to use default namespace because mx
and spark code generation work differently, and there's no way otherwise
for the compiler to know, which one to use. So, having mandatory namespace
solves the problem, but in a bad, non-generic way. It would be best if code
generation didn't rely on namespace used (because there is no logical
dependency between the two).
I would see this as a big step forward, and was advocating this before, if
the code generation mechanism was made available to developer. S.t. for
example it would be based on templates, or rule sets. The solution Adobe
came up with is a typical "enterprise" kind of thinking - trying to deal
with outcomes rather then fixing the source of the problem.
Imagine the example below:
[Mixin]
public class FlexInit {
public static function init():void {
${Accessibility initialization block}
${AMF aliases registration block}
. . .
}
This is the code that might have been used to generate FlexInit class. So
that if it was your project, and you knew you aren't going to implement
accessibility anyways, you could loose the first block. If you wanted to
override the default behavior of AMF aliases registration - again, you
would be able to do so. More yet, if you didn't want this template to be
used - you'd have to remove it, and the mention of it from other templates.
Similarly, the rules of translation of arbitrary MXML code into AS3 could
be expressed in some CFG-like language, so that if you wanted to alter the
way attributes are treated, add, for example, access modifiers, constants
usage etc. you would have something like:
identifier := ${access modifier} ${static} 'var' ${node name} ':' ${type
specifier} (initializer)*
rule, which would take certain parts of an XML node and replace the ${...}
with respective content. This would've create a really generic and reusable
system. On the other hand, having MXML templates hardcoded into compiler
has a "potential" of, for example, breaking all projects of all users in
some subtle way for the life time of the release.
Best.
Oleg
