incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <>
Subject Re: Flex and names spaces in MXML
Date Fri, 16 Mar 2012 23:37:12 GMT
No-no-no :)
Framework code is an extension, an add-on. There is absolutely no reason it
should get into "default" namespace. There is enough frustration as it is
about all sorts of non-built-in AS3 code that Adobe tossed into Flash CS,
and made the use mandatory. Please don't add even more to it. All these
http.../mx, http.../halo etc namespaces are no default. A lot of people
using Flex (compiler) don't need them and don't want them.

Too little profit for too many changes. If you want to make really good
template language - forget about XML at all, it's not meant to be a good
template language, it has never been designed to be it. The benefits of
having XML as a template language are that other tools support it already
and that it is familiar to the users. If you lose the first benefit and you
confuse your users, you are left with nothing.

After all, I seriously think that what namespace there should be is
irrelevant, the actual task is to make it so it is most flexible. Flexible,
in my understanding is "possible to substitute or remove". I.e. if I wanted
to put List class into default namespace, while not using Flex framework, I
wouldn't have to deal with any naming collisions. This is, by the way,
quite realistic requirement, because, for reasons beyond my comprehension,
in Flex framework, List names a graphical component, while any programmer
with some experience would expect List to be a data structure.
Well, it's like Java classes are in java.lang.* package, Lisp default
functions are in common-lisp-user package, .NET core classes are in
Windows.* namespace etc. Default namespace is for the programmers, not the
language (and they shouldn't really use it too, unless maybe for

After all, you really look at it from a perspective of someone who only
used MXML for one particular thing and that's why the solution you are
trying to offer might look logical to you, but it absolutely doesn't fit in
other use cases. As I mentioned above: UIComponent isn't a requirement for
MXML, so, if, as you suggested before, these namespaces were defined in
UIComponent, other legitimate uses would suffer from it because they would
have to bring in UIComponent class, and you really don't want to feed
that monstrously obese piece of code to the compiler, once your entire
project may be 10000 (ten thousands!) times smaller than that thing.
Now, is there a particular class, which is a requirement for MXML? - no,
there isn't any. So, you don't have a place to store these namespaces, even
if it was somehow technically possible.

Using some other template language to generate AS3? - yup, that's
interesting :) I was once thinking about some very simple language for
describing resource files. My first idea was CSS, but then I realized it is
overly complex (has redundant parts), then I looked at Protobuf - cool, but
it would be difficult to add Flash-specific things and it already requires
things impossible in Flash (64-bit integers). I was thinking about
something like JSON, but it's overly verbose and doesn't allow references.
I finally stopped at symbolic expressions, but got some other things to do
:) Though I think that it could actually work.



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