| Thread overview | ||||||||
|---|---|---|---|---|---|---|---|---|
|
June 10, 2015 Potential abuse of .stringof | ||||
|---|---|---|---|---|
| ||||
I am a little concerned about the discussion here (https://github.com/D-Programming-Language/phobos/pull/3394#discussion_r31953154) pertaining to the usage (or abuse) of .stringof. [1] https://github.com/D-Programming-Language/phobos/pull/3394#discussion_r31953154 JC: I've been told that stringof shouldn't be used for anything other than debugging. Is there something else that can be used? There's no guarantee that the result is stable? AA: there was no other way I could do it ML: A lot of the time there really is no other way. A large amount of code in this vein that I've written invariably ends up needing stringof as well. Maybe we should provide stronger guarantees about what stringof produces. AA: Well it'll break the unittests that's for sure :). The problem here is with the function parameter lists. There is no way to express storage classes such as ref, out, lazy as parts of types. I also think .stringof for types should offer better guarantees. The simplest one is, for non-Voldemort types, pasting the string into source code should be parsable as a type. Today that's not always the case. I smell an action item here. What can be done to make this less of "There's no other way to do it" and more "That's how it should be done"? Mike | ||||
June 10, 2015 Re: Potential abuse of .stringof | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Mike | On 6/9/15 5:09 PM, Mike wrote:
> I smell an action item here. What can be done to make this less of
> "There's no other way to do it" and more "That's how it should be done"?
An effective solution is to specify .stringof to return types that are valid D types (i.e. can be pasted in D code and aliased to identifiers). Exceptions: Voldemort types and function types.
Andrei
| |||
June 10, 2015 Re: Potential abuse of .stringof | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2015-06-10 02:50, Andrei Alexandrescu wrote: > An effective solution is to specify .stringof to return types that are > valid D types (i.e. can be pasted in D code and aliased to identifiers). > Exceptions: Voldemort types and function types. Is that enough? The original problem I had, and the reason for my comment on GitHub, was that I had used .stringof on a member of .tupleof to get the name of an instance variable. Originally .stringof returned a string containing both the name of the type and the name of the instance variable. Then in some release it was change to return just the name of the instance variable. -- /Jacob Carlborg | |||
June 10, 2015 Re: Potential abuse of .stringof | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 10 June 2015 at 00:50:48 UTC, Andrei Alexandrescu wrote: > Exceptions: Voldemort types and function types. Why not Voldemort types? Example: http://dpaste.dzfl.pl/450dcdb5f7f8 ------------------------------------------- import std.stdio; auto createVoldemortType(int value) { struct TheUnnameable { int getValue() { return value; } } return TheUnnameable(); } void main() { auto voldemort = createVoldemortType(123); writeln(typeof(voldemort).stringof); } ------------------------------------------- Seems to return the correct result, although it "TheUnnameable" cannot be cut and pasted outside of the createVoldemortType scope. Perhaps that's the limitation you are referring to. Mike | |||
June 10, 2015 Re: Potential abuse of .stringof | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Mike | On 6/9/15 11:59 PM, Mike wrote:
> Seems to return the correct result, although it "TheUnnameable" cannot
> be cut and pasted outside of the createVoldemortType scope. Perhaps
> that's the limitation you are referring to.
Yah, and the problem here is that outside createVoldemort, the same typename could refer to a different type. -- Andrei
| |||
June 10, 2015 Re: Potential abuse of .stringof | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 10 June 2015 at 15:39:51 UTC, Andrei Alexandrescu wrote: > On 6/9/15 11:59 PM, Mike wrote: >> Seems to return the correct result, although it "TheUnnameable" cannot >> be cut and pasted outside of the createVoldemortType scope. Perhaps >> that's the limitation you are referring to. > > Yah, and the problem here is that outside createVoldemort, the same typename could refer to a different type. -- Andrei import std.stdio; import std.traits; auto createVoldemortType(int value) { struct TheUnnameable { int getValue() { return value; } } return TheUnnameable(); } void main() { auto voldemort = createVoldemortType(123); //f57.main.voldemort writeln(fullyQualifiedName!voldemort); } fullyQualifiedName doesn't work for Voldemort types; is there a way that we could change this? Then at least you could do: fullyQualifiedName!voldemort ~ typeof(voldemort).stringof | |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply