Re: The worst Phobos template (in binderoo)
On Saturday, 1 October 2016 at 19:54:13 UTC, Dicebot wrote: On Saturday, 1 October 2016 at 15:06:44 UTC, Stefan Koch wrote: The problem is the default template parameter Flag!"unsafe", because fqn makes it into "cast(Flag)". Getting this right is a bit tricky. Isn't it a problem with library implementation though, one that would be easy to fix if FQN is to become a compiler built-in? It is easier then doing it in a template for sure. But it still requires a bit of AST-traversal. And I fear differing from phobos could make it harder to get the PR merged. since the __trait is supposed to be a drop-in replacement for the phobos template.
Re: The worst Phobos template (in binderoo)
On Saturday, 1 October 2016 at 15:06:44 UTC, Stefan Koch wrote: On Saturday, 1 October 2016 at 10:19:21 UTC, Dicebot wrote: On 09/29/2016 07:02 PM, David Nadlinger wrote: [...] What are the issues with fullyQualifiedName in that context? I mean other than Voldemort types of course. I'd expect `static import` + `fullyQualifiedName` combo to be reasonably reliable and used it a lot in the past. Do you refer to aliases with changed protection attributes? The problem is the default template parameter Flag!"unsafe", because fqn makes it into "cast(Flag)". Getting this right is a bit tricky. Isn't it a problem with library implementation though, one that would be easy to fix if FQN is to become a compiler built-in? Reason why I'd like to have something akin to FQN for code generation is because it allow to generate (and save to file) non-templated methods directly importing required symbols (only generator function has to be templated). This can be of great importance if you consider classes and virtual methods.
Re: The worst Phobos template (in binderoo)
On Saturday, 1 October 2016 at 10:19:21 UTC, Dicebot wrote: On 09/29/2016 07:02 PM, David Nadlinger wrote: [...] What are the issues with fullyQualifiedName in that context? I mean other than Voldemort types of course. I'd expect `static import` + `fullyQualifiedName` combo to be reasonably reliable and used it a lot in the past. Do you refer to aliases with changed protection attributes? The problem is the default template parameter Flag!"unsafe", because fqn makes it into "cast(Flag)". Getting this right is a bit tricky.
Re: The worst Phobos template (in binderoo)
On 09/29/2016 07:02 PM, David Nadlinger wrote:
> On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner wrote:
>> Any chance to get this one working:
>>
>> import std.typecons;
>>
>> enum Stuff
>> {
>> asdf,
>> }
>>
>> void main()
>> {
>> BitFlags!Stuff a;
>> mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
>> }
>
> This wouldn't be a correct use of the feature anyway, since it runs into
> all sorts of fundamental issues with imports/scoping, aliases and
> templates. Using .stringof/fullyQualifiedName to generate a reference to
> a type or symbol in a string mixin is a mistake, period. Unfortunately,
> the misconception that they *are* code generation tools is fairly
> wide-spread, to the point where dlang.org contains a similarly
> misleading comment. [1]
What are the issues with fullyQualifiedName in that context? I mean
other than Voldemort types of course. I'd expect `static import` +
`fullyQualifiedName` combo to be reasonably reliable and used it a lot
in the past. Do you refer to aliases with changed protection attributes?
signature.asc
Description: OpenPGP digital signature
Re: The worst Phobos template (in binderoo)
On 09/29/2016 03:27 PM, Timon Gehr wrote: On 16.09.2016 01:10, Andrei Alexandrescu wrote: On 9/15/16 7:08 PM, Andrei Alexandrescu wrote: Yes, that DIP. It would need some more formal work before defining an implementation. Stefan, would you want to lead that effort? -- Andrei Actually I see Timon authored that (I thought it's an older DIP by Walter). Timon, would you want to finalize the definition so Stefan can write an implementation? Thx! -- Andrei I have been wanting to do that for a long time. I'll try to find some time next week. That would be awesome, thanks! -- Andrei
Re: The worst Phobos template (in binderoo)
On 16.09.2016 01:25, Stefan Koch wrote: On Thursday, 15 September 2016 at 23:08:54 UTC, Andrei Alexandrescu wrote: Yes, that DIP. It would need some more formal work before defining an implementation. Stefan, would you want to lead that effort? -- Andrei I am not good at defining semantics, yet I would participate in a joint effort with Timon. ... Sounds good. Be aware though that I am currently working at improving templates. And there might a significant win to be had.
Re: The worst Phobos template (in binderoo)
On 16.09.2016 01:10, Andrei Alexandrescu wrote: On 9/15/16 7:08 PM, Andrei Alexandrescu wrote: Yes, that DIP. It would need some more formal work before defining an implementation. Stefan, would you want to lead that effort? -- Andrei Actually I see Timon authored that (I thought it's an older DIP by Walter). Timon, would you want to finalize the definition so Stefan can write an implementation? Thx! -- Andrei I have been wanting to do that for a long time. I'll try to find some time next week.
Re: The worst Phobos template (in binderoo)
On Thursday, 29 September 2016 at 16:30:56 UTC, Eugene Wissner wrote: The problem is you can never know all the use cases of some feature. It is just pointless to try to predict where a user will need a feature. I had a use case where I could be sure that everything needed is imported and where I could save compile time and make the function signatures a bit simpler. Let us just remove fullyQualifiedName from the language. Why spend effort with it? Why should one write into the documentation: Oh, you thought it would work? How funny! This function is just for fun of the library creators and is only good to pass it to writeln(), it isn't supposed to work. The point is that the fullyQualifiedName of something is not always enough to generate that type. As you have seen in your usecase.
Re: The worst Phobos template (in binderoo)
On Thursday, 29 September 2016 at 16:02:53 UTC, David Nadlinger
wrote:
This wouldn't be a correct use of the feature anyway, since it
runs into all sorts of fundamental issues with imports/scoping,
aliases and templates. Using .stringof/fullyQualifiedName to
generate a reference to a type or symbol in a string mixin is a
mistake, period. Unfortunately, the misconception that they
*are* code generation tools is fairly wide-spread, to the point
where dlang.org contains a similarly misleading comment. [1]
Just emit the typeof expression into the mixin string, e.g.
`mixin("typeof(a) c;");`. It should be fairly easy to convince
yourself that a similar rewrite is always possible, even if it
is sometimes less obvious (in some situations, you might need
to change some code to, say, pass on a template parameter `T`
all the way to the point of the mixin() call instead of
`T.stringof`).
— David
[1] https://github.com/dlang/dlang.org/pull/380
Maybe it is correct about the usage of
.stringof/fullyQualifiedName. But I still don't understand the
argumentation. Why it is so bad if something works as expected,
why it is so evil if fullyQualifiedName would return what is
says: the fully qualified name.
The problem is you can never know all the use cases of some
feature. It is just pointless to try to predict where a user will
need a feature. I had a use case where I could be sure that
everything needed is imported and where I could save compile time
and make the function signatures a bit simpler.
Let us just remove fullyQualifiedName from the language. Why
spend effort with it? Why should one write into the
documentation: Oh, you thought it would work? How funny! This
function is just for fun of the library creators and is only good
to pass it to writeln(), it isn't supposed to work.
Re: The worst Phobos template (in binderoo)
On Thursday, 29 September 2016 at 14:49:03 UTC, Stefan Koch wrote: The reason why this fails is because of the cast(Flag) which should be cast(Flag!"unsafe"). I can probably make it work tough, that means more special casing :) Yes, I know. See this topic for the first discussion: http://forum.dlang.org/post/igsxmowtguwvngnqu...@forum.dlang.org It would be really great :)
Re: The worst Phobos template (in binderoo)
On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner
wrote:
Any chance to get this one working:
import std.typecons;
enum Stuff
{
asdf,
}
void main()
{
BitFlags!Stuff a;
mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
}
This wouldn't be a correct use of the feature anyway, since it
runs into all sorts of fundamental issues with imports/scoping,
aliases and templates. Using .stringof/fullyQualifiedName to
generate a reference to a type or symbol in a string mixin is a
mistake, period. Unfortunately, the misconception that they *are*
code generation tools is fairly wide-spread, to the point where
dlang.org contains a similarly misleading comment. [1]
Just emit the typeof expression into the mixin string, e.g.
`mixin("typeof(a) c;");`. It should be fairly easy to convince
yourself that a similar rewrite is always possible, even if it is
sometimes less obvious (in some situations, you might need to
change some code to, say, pass on a template parameter `T` all
the way to the point of the mixin() call instead of `T.stringof`).
— David
[1] https://github.com/dlang/dlang.org/pull/380
Re: The worst Phobos template (in binderoo)
On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner
wrote:
On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch
wrote:
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch
wrote:
I would like to see users of fullyQualifiedName because apart
from binderoo code which seems to work, I have none.
That was supposed to say : I would like to see [test cases
from] users of fullyQulifiedName.
Any chance to get this one working:
import std.typecons;
enum Stuff
{
asdf,
}
void main()
{
BitFlags!Stuff a;
mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
}
?
Btw __traits(fullyQualifiedName, typeof(a)) generates:
std.typecons.BitFlags!(Stuff, cast(Flag)false)
std.traits.fullyQualifiedName generates:
std.typecons.BitFlags!(fqn.Stuff, cast(Flag)false)
("fqn" is the name of the executable)
The reason why this fails is because of the cast(Flag) which
should be cast(Flag!"unsafe").
I can probably make it work tough,
that means more special casing :)
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch
wrote:
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch
wrote:
I would like to see users of fullyQualifiedName because apart
from binderoo code which seems to work, I have none.
That was supposed to say : I would like to see [test cases
from] users of fullyQulifiedName.
Any chance to get this one working:
import std.typecons;
enum Stuff
{
asdf,
}
void main()
{
BitFlags!Stuff a;
mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
}
?
Btw __traits(fullyQualifiedName, typeof(a)) generates:
std.typecons.BitFlags!(Stuff, cast(Flag)false)
std.traits.fullyQualifiedName generates:
std.typecons.BitFlags!(fqn.Stuff, cast(Flag)false)
("fqn" is the name of the executable)
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: I am going to submit a PR soon. https://github.com/dlang/dmd/pull/6134 Here it is.
Re: The worst Phobos template (in binderoo)
On Friday, 16 September 2016 at 00:57:13 UTC, Stefan Koch wrote: When polished CTFE can totally be used as a serious workhorse for cases that would have fallen intro the static foreach category. When you get your polished CTFE finished, you might consider a blog post on it (including an example with use cases for static foreach would be cool too).
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 23:25:34 UTC, Stefan Koch wrote: On Thursday, 15 September 2016 at 23:08:54 UTC, Andrei Alexandrescu wrote: Yes, that DIP.[http://wiki.dlang.org/DIP57] It would need some more formal work before defining an implementation. Stefan, would you want to lead that effort? -- Andrei I am not good at defining semantics, yet I would participate in a joint effort with Timon. I thought some more about this. static foreach is probably not a good idea at this point. We should focus on getting the existing features to do their job properly and we won't have to add yet more meanings to the word static. Our code-generation facilities with CTFE and mixins are very good indeed. When polished CTFE can totally be used as a serious workhorse for cases that would have fallen intro the static foreach category.
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 23:08:54 UTC, Andrei Alexandrescu wrote: Yes, that DIP. It would need some more formal work before defining an implementation. Stefan, would you want to lead that effort? -- Andrei I am not good at defining semantics, yet I would participate in a joint effort with Timon. Be aware though that I am currently working at improving templates. And there might a significant win to be had.
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 22:58:12 UTC, Stefan Koch wrote: The Performance-Penalty will be less then on templates. Let me add a disclaimer, I _think_ the performance penalty _can_ be less then the penalty on templates. Also static if can sometimes lead to counter-intuitive situations, static foreach will likely be worse in that regard. Implementation issues aside, and the DIP aside. What would be the semantics you would want for this ?
Re: The worst Phobos template (in binderoo)
On 9/15/16 7:08 PM, Andrei Alexandrescu wrote: Yes, that DIP. It would need some more formal work before defining an implementation. Stefan, would you want to lead that effort? -- Andrei Actually I see Timon authored that (I thought it's an older DIP by Walter). Timon, would you want to finalize the definition so Stefan can write an implementation? Thx! -- Andrei
Re: The worst Phobos template (in binderoo)
On 9/15/16 6:58 PM, Stefan Koch wrote: On Thursday, 15 September 2016 at 14:43:16 UTC, Stefan Koch wrote: On Thursday, 15 September 2016 at 14:38:41 UTC, Andrei Alexandrescu wrote: On 09/15/2016 10:08 AM, Stefan Koch wrote: static foreach on the other hand is a whole new can of worms. As walter will be able to tell you. It's time to open it. -- Andrei Please give me an example on how it should work. Are we talking about http://wiki.dlang.org/DIP57 ? I think I can give you a partial solution for that. The Performance-Penalty will be less then on templates. However I can smell a bunch of un-intuitive corner-cases hiding in there. Yes, that DIP. It would need some more formal work before defining an implementation. Stefan, would you want to lead that effort? -- Andrei
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 14:43:16 UTC, Stefan Koch wrote: On Thursday, 15 September 2016 at 14:38:41 UTC, Andrei Alexandrescu wrote: On 09/15/2016 10:08 AM, Stefan Koch wrote: static foreach on the other hand is a whole new can of worms. As walter will be able to tell you. It's time to open it. -- Andrei Please give me an example on how it should work. Are we talking about http://wiki.dlang.org/DIP57 ? I think I can give you a partial solution for that. The Performance-Penalty will be less then on templates. However I can smell a bunch of un-intuitive corner-cases hiding in there.
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 14:38:41 UTC, Andrei Alexandrescu wrote: On 09/15/2016 10:08 AM, Stefan Koch wrote: static foreach on the other hand is a whole new can of worms. As walter will be able to tell you. It's time to open it. -- Andrei Please give me an example on how it should work.
Re: The worst Phobos template (in binderoo)
On 09/15/2016 10:08 AM, Stefan Koch wrote: static foreach on the other hand is a whole new can of worms. As walter will be able to tell you. It's time to open it. -- Andrei
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 13:49:46 UTC, Andrei Alexandrescu wrote: On 09/15/2016 09:27 AM, Stefan Koch wrote: On Thursday, 15 September 2016 at 13:20:16 UTC, Andrei Alexandrescu wrote: On 09/15/2016 08:35 AM, Stefan Koch wrote: On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei Alexandrescu wrote: Apparently we need that static foreach iteration. -- Andrei What exactly do you mean ? As long as we instanciate n templates for a member nested n levels the overhead is massive! How would static foreach help ? I thought staticMap is just a (simulated) loop that applies the same template in sequence. -- Andrei staticMap is a recursive variadic template. Can recursion be replaced with iteration? Assume you have static foreach at your disposal. -- Andrei You tell me, you are the expert on templates :o) I cannot be certain but I think, It would probably work. static foreach on the other hand is a whole new can of worms. As walter will be able to tell you.
Re: The worst Phobos template (in binderoo)
On 09/15/2016 09:27 AM, Stefan Koch wrote: On Thursday, 15 September 2016 at 13:20:16 UTC, Andrei Alexandrescu wrote: On 09/15/2016 08:35 AM, Stefan Koch wrote: On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei Alexandrescu wrote: Apparently we need that static foreach iteration. -- Andrei What exactly do you mean ? As long as we instanciate n templates for a member nested n levels the overhead is massive! How would static foreach help ? I thought staticMap is just a (simulated) loop that applies the same template in sequence. -- Andrei staticMap is a recursive variadic template. Can recursion be replaced with iteration? Assume you have static foreach at your disposal. -- Andrei
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 13:20:16 UTC, Andrei Alexandrescu wrote: On 09/15/2016 08:35 AM, Stefan Koch wrote: On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei Alexandrescu wrote: Apparently we need that static foreach iteration. -- Andrei What exactly do you mean ? As long as we instanciate n templates for a member nested n levels the overhead is massive! How would static foreach help ? I thought staticMap is just a (simulated) loop that applies the same template in sequence. -- Andrei staticMap is a recursive variadic template. CompileTime wise the worst class a template can be in. it expands to a series of templates instancing itself log(n) times. causing 2n*log(n) instances in total. It's not a pretty picture.
Re: The worst Phobos template (in binderoo)
On 09/15/2016 08:35 AM, Stefan Koch wrote: On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei Alexandrescu wrote: Apparently we need that static foreach iteration. -- Andrei What exactly do you mean ? As long as we instanciate n templates for a member nested n levels the overhead is massive! How would static foreach help ? I thought staticMap is just a (simulated) loop that applies the same template in sequence. -- Andrei
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei Alexandrescu wrote: Apparently we need that static foreach iteration. -- Andrei What exactly do you mean ? As long as we instanciate n templates for a member nested n levels the overhead is massive! How would static foreach help ?
Re: The worst Phobos template (in binderoo)
On 09/14/2016 05:50 PM, Stefan Koch wrote: On Wednesday, 14 September 2016 at 21:06:10 UTC, Andrei Alexandrescu wrote: On 09/14/2016 04:52 PM, Stefan Koch wrote: [...] (Disclaimer: I didn't run any speed tests.) By looking at the definition of fullyQualifiedName it seems to me we can go a long way with traditional optimization techniques. For example consider: [...] staticMap is number 3 in the top-slow-templates list. And the code inside it really does not matter so much. What matters is recursive instanciation. the evaluation of the function is fast in comparison to the time the template-subsystem takes. I believe this cannot be fixed by changing a library solution. Apparently we need that static foreach iteration. -- Andrei
Re: The worst Phobos template (in binderoo)
On Thursday, 15 September 2016 at 06:08:33 UTC, Dicebot wrote:
mixin("alias T2 = " ~ fqn!T);
static assert(is(T2 == T));
In that sense builtin trait could be a better option.
Yes a builtin trait is the better option.
I made a youtube video about that.
Showing you how bad FullyQualifiedName is and how much better a
trait is.
https://www.youtube.com/watch?v=l1Ph3Nn0en0
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch
wrote:
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch
wrote:
I would like to see users of fullyQualifiedName because apart
from binderoo code which seems to work, I have none.
That was supposed to say : I would like to see [test cases
from] users of fullyQulifiedName.
I wrote a type overload of it long time ago to be used in vibe.d
REST interface generator - combined with static imports it
ensured symbol hygienne. Though it possible current
implementation doesn't use it anymore.
Intended semantics was to be as close to this as possible:
mixin("alias T2 = " ~ fqn!T);
static assert(is(T2 == T));
In that sense builtin trait could be a better option.
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch wrote: On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none. That was supposed to say : I would like to see [test cases from] users of fullyQulifiedName. I use it in unit_threaded, which now explains why the compile-time reflection is a bit slow. I need to figure out how to measure it though. Atila
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 22:48:29 UTC, Pierre Krafft wrote: I've had to use fullyQualifiedName in some string mixins. Unless there is more to the example than what meets the eye, "had to" isn't quite true, and even with the `import moduleName!…` hack, your code is still unnecessarily restrictive. Just use ` ~ "fromJSON!(typeof(t." ~ name ~ "))…"` instead. I'd really like to know where the notion that stringifying symbols for mixin code generation is a viable choice comes from. People seem to try with an irritating regularity, only to inevitably discover that it doesn't actually work some time later. That one can get dangerously close now that we have `moduleName` doesn't exactly help either. — David
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none. I've had to use fullyQualifiedName in some string mixins. Take a look at https://github.com/BlackEdder/painlessjson/blob/9f9b94b3a47ada4ffdea16ef5dc5476c74cb9a06/source/painlessjson/painlessjson.d#L415. I also recommend using GitHub search to find other examples.
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 21:06:10 UTC, Andrei Alexandrescu wrote: On 09/14/2016 04:52 PM, Stefan Koch wrote: [...] (Disclaimer: I didn't run any speed tests.) By looking at the definition of fullyQualifiedName it seems to me we can go a long way with traditional optimization techniques. For example consider: [...] staticMap is number 3 in the top-slow-templates list. And the code inside it really does not matter so much. What matters is recursive instanciation. the evaluation of the function is fast in comparison to the time the template-subsystem takes. I believe this cannot be fixed by changing a library solution.
Re: The worst Phobos template (in binderoo)
On 09/14/2016 04:52 PM, Stefan Koch wrote:
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote:
It takes a whooping 500 milliseconds
Ahm... I misread my performance graph
it's 138ms for the first instanciation.
and around 5ms for every following one.
the total time spent on it was 500ms
(Disclaimer: I didn't run any speed tests.) By looking at the definition
of fullyQualifiedName it seems to me we can go a long way with
traditional optimization techniques. For example consider:
string result = join(
map!(a => format("%s%s", a[0], a[1]))(
zip([staticMap!(storageClassesString, parameterStC)],
[staticMap!(fullyQualifiedName, parameters)])),
This is neat, and it's neat squared because it works during compilation,
but at some point if the resulting code runs slowly, there's no shame in
applying old school optimization. Instead of join/map a simple loop
should suffice; no need to use format with "%s%s" over simple
concatenation; array zipping may be done with simple loops too.
Same a few lines below - just replace return format("%s%s%s%s%s%s%s%s",
...) with simple concatenation. Same goes with format("shared(%s)",
...), format("%s(%s)", ...) etc. In casual runtime code such code is
totally fine, but in library code we'd do good to eliminate the use of
format (which is a mini-interpreter) if speed considerations tell us to.
The unittests seem excessive too. Yes, there is such a thing as too much
of a good thing. And use a lot of format during compilation as well :o).
In unittests, a bunch of static asserts may be replaced with regular
asserts.
Andrei
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: It takes a whooping 500 milliseconds Ahm... I misread my performance graph it's 138ms for the first instanciation. and around 5ms for every following one. the total time spent on it was 500ms
Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none. That was supposed to say : I would like to see [test cases from] users of fullyQulifiedName.
