I think adding a default namespace only adds confusion. "So why do I leave this components namespace blank and set another?"
I would drop the idea for default namespaces On Mar 16, 2012 6:37 PM, "Left Right" <olegsivo...@gmail.com> wrote: > 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 > experiments). > > 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. > > Best. > > Oleg >
