The gain is that the author has at edit time full control over where the link points to. With runtime lookup a link might change because a certain term was added to a certain namespace.
-- Jan Hidders
Well, that's not a bug but a feature! The term will not be added to a certain namespace if there isn't already some disrepancy (and if the author means the other subject he will surely link to it explicitly, like [[Root (Botanics)]]) By doing the linking in runtime we could make sure that all links point at their most updated targets, which is an advantage. This is similar to the reason why we use redirects.
As to runtime performance concerns, I'm sure that caching and/or an optimised parser could do wonders in the Wikipedia case. Wiki markup is _very light_.
Sincerely yours, Uri Yanover
From: "Uri Yanover" uriyan_subscribe@yahoo.com
The gain is that the author has at edit time full control over where the link points to. With runtime lookup a link might change because a
certain
term was added to a certain namespace.
And, of course, as Lee already pointed out, it also makes it less tempting for the casual user. A very important argument.
Well, that's not a bug but a feature! The term will not be added to a certain namespace if there isn't already some disrepancy (and if the author means the other subject he will surely link to it explicitly, like [[Root (Botanics)]]) By doing the linking in runtime we could make sure that all links point at their most updated targets, which is an advantage. This is similar to the reason why we use redirects.
Perhaps the user wants this to happen, perhaps not. I suggest we first wait and see how many people actually need such features.
As to runtime performance concerns, I'm sure that caching and/or an optimised parser could do wonders in the Wikipedia case. Wiki markup is _very light_.
Have you seen the parsing code? There is nothing _very light_ about it, at the moment. I intend to improve that in the future, but found some other problems I would like to solve first. Anyway, adding non-trivial features is not going to make that job easier.
Kind regards,
-- Jan Hidders
And, of course, as Lee already pointed out, it also makes it less tempting for the casual user. A very important argument.
There are 24000 articles now that don't use aliases; they're relatively difficult to set up, and so it's not likely for them to become a major subject of abuse.
Perhaps the user wants this to happen, perhaps not. I suggest we first
wait
and see how many people actually need such features.
_I_ need this feature. I also feel that bringing subpages back from the dead the way this proposal stands is wrong
As to runtime performance concerns, I'm sure that caching and/or an optimised parser could do wonders in the Wikipedia case. Wiki markup is _very light_.
Have you seen the parsing code? There is nothing _very light_ about it, at the moment. I intend to improve that in the future, but found some other problems I would like to solve first. Anyway, adding non-trivial features
is
not going to make that job easier.
I must admit that I did not see the code; however the wiki markup is really simple, compared to most other markup and general-use languages out there. High-performance parsers exist; I believe that eventually the Wiki parser will match them.
If we really want to improve performance, perhaps we should simplify some syntax structures (e.g. doing ISBNs through links [ISBN 200145-3453|this way]), write a formal grammar and then write a parser in C (or some other high-performance language) to reflect that formal grammar. But I digress :-).
Sincerely yours, Uri Yanover
wikipedia-l@lists.wikimedia.org