Just a slight point here, and this point is getting very theoretical, but think this is the level the thinking should be at when designing a language. And I like to think about stuff.
Also I’ll put it up front that whilst I think the empty namespace is a poor idea, I’m not really that fussed. But now is the time we should be thinking about this.
The absence of a namespace doesn’t mean “this is Lucee”, it means “I make no claims as to what this is”. You infer it means Lucee because of the context of it being in a .lucee file, and you are arriving at that file already knowing this. Obviously one can easily do that. But should one do that? IE: should that be how this is resovled?
The thing with populated namespaces is that the prefix does indicate “this is [whatever]”, as it correlates back to the namespace declaration earlier in the doc). This namespace decl. could be in a tag or could be in a taglib import statement or implied or whatever.
In the context of a file full of HTML which is ultimately going to be streamed back for the intent to be used as HTML in a bigger repsonse, then the raw HTML “namespace” needs to win out for the sake of expediency (imagine needing to type out “<html:br>
”!), so it’s just presented as HTML. From there, any non HTML should be (well: “could be”, but we’ve erred towards “it will”) presented with a namespace to identify it.
We should bear in mind that .lucee code will not exist in a vacuum. It might be being used where other taglibs are being used, and the idea being namespaces is to disambiguate between the libs. For example in our views we’d be using our own custom tag libraries, and/or someone else’s custom tag libraries, or just have multiple custom taglibs of our own, etc. Or I guess even in other mark-up which already uses namespaces: generating XML or [some future thing which becomes all the rage]. The point being, namespaces work the way they do for a reason: a bigger picture.
We also need to think that .lucee doesn’t exist in a vacuum in the context of how namespaces in tag-like text works. But rather from the perspective of the rest of the industry. It’s true that a .lucee file isn’t XML and makes no claim to be. However we are borrowing syntax from XML… I mean we have chosen to use “<[blank]:tagname
” as our syntax, and do indeed claim the colon is the namespace separator. So we’re borrowing from XML. But in the next breath some of us are going “no we’re not using XML” when countering the suggestions that XML namespaces usually aren’t empty. If we didn’t want to run with the way XML does its namespacing… we could have used a prefix instead (ie: "<[prefix][tagname]"
, “<cfclient
”).
I think we’re using broader industry conceits, but then only thinking very locally in its implementation, ignoring the way the broader industry does things. I think this is not the way other languages’ design decisions are generally made. We still seem to be slightly stuck in the “everything is our own little world” that CFMLers tend to reside in.
On the other hand, so far the only legit (-ish) rationale for not using an actual namespace is “it saves typing”, which I think only stands up if one is in a typing race. That said, some have indicated they think that they are, so I can see where that comes from.
@alexskinner made a valid point earlier than “<l:
” and “<lc:
” is unclear as to whether it’s a “1
” or an “l
” or an “I
”. This is true when taken out of any context. However it only becomes relevant in a context where there a mix of two or more of those possibilities. In a source code file you’re looking at: “<lc:
” means “Lucee”. It’s an L. If you then import another taglib and choose to use one-cee or eye-cee as its prefix: more fool you.
So I think the lack of namespace prefix has been justified via excuse, rather than via rationale.
Still, like I said… I don’t care so much I suppose. I’m more like juror 12 in 12 Angry Men who just wants to hold up the decision for a bit whilst we think about it some more.
And whichever approach is ultimately taken: I don’t think it’ll be the end of the world one bit… the code will still work [grin].
Cheers for wading through all that!
–
Adam