Re: User Defined Attributes
On Thursday, 15 November 2012 at 22:04:27 UTC, David Nadlinger
wrote:
On Thursday, 15 November 2012 at 08:45:49 UTC, Tove wrote:
I disagree, you can always fallback to using user defined
types... but it _allows_ for native types also, i.e. more
flexible.
You are missing the point: In your proposal, if you want to use
two libraries together which are expecting you to provide e.g.
'int' annotations, you are screwed. This is a big, BIG problem.
David
no, I implied the solution already... actually there are many
different ways to solve it... some possible today, some require
new minor support features(like sending the annotated symbol as a
template alias parameter to the annotation)... but could give us
compile time errors when ambiguity is detected.
In the common case there are no collisions, so most of the time
we can use the nice user-friendly syntax!
[lib1.x]
struct User
{
[1] int uid;
}
But we _can_ disambiguate when needed...
[lib1.x, lib2.y]
struct User
{
[lib!1, lib2!2] int uid; // ok
[1, lib2!2] int uid; // ok
[lib1!1, 2] int uid; // ok
[1,2] int uid; // not supported
[1] int uid; // not supported
}
lib2 doesn't have to know about lib1.
lib1 doesn't have to know about lib2.
Because they just have to check the annotation in _prioritized_
order.
1. find my unique lib2.y symbol
2. if there is a lib2!uint on a nested symbol, use it...
3. if not check for a native int.
Re: User Defined Attributes
On 11/15/2012 12:22 AM, Jacob Carlborg wrote:
On 2012-11-14 22:13, Walter Bright wrote:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Just because it is not a builtin type does not change anything.
Sure you _can_ but it would be quite stupid. With user defined types there is at
least some context. With a plain string (or any built in type) it can come from
any where and mean anything.
The difference is, with a user defined type you know the meaning of the
attribute, with a built in type you do not, not in the same way at least.
The whole point of my example was no, you do not necessarily know the meaning of
a user-defined type that is used as an attribute.
Re: User Defined Attributes
On Friday, 16 November 2012 at 10:41:44 UTC, Walter Bright wrote:
The whole point of my example was no, you do not necessarily
know the meaning of a user-defined type that is used as an
attribute.
Agree. Imagine we have 3 generic libs/modules...
Optimized CTFE Polygon Primitive Lib, Math, Gfx
... and then the end user, creates a program.
Both Math and Gfx, want to use the optimized Polygon in their
modules...
[Polygon(...)]
struct SpaceShip
{
}
This is just as ambiguous as if you had used a built-in int:s...
and it can be solved in the exact same way which I outlined in
the other thread.
Re: User Defined Attributes
Le 14/11/2012 22:13, Walter Bright a écrit :
On 11/14/2012 2:53 AM, Jacob Carlborg wrote:
If std.mytypes.mystring is a variable of the type string then the
fully
qualified name is lost if it's used as an attribute. Something like this:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Now use MyString as an attribute. No, the name is not lost. Yes, two
different modules can use MyString as an attribute, and impute
completely different meanings into it.
Just because it is not a builtin type does not change anything.
I seriously feel like I'm in Alice in wonderland here.
A type is a meaning associated to data. For instance, char[] is an array
of char. Note that you can store pointers, integer, or basically
anything in that memory. But you don't, because this type give you
information about what in this memory, and storing anything else would
be confusing as hell.
The same way, I can throw a FileExeption every time a problem occurs in
any of my programs. That would be insane, but i CAN do that.
Well, the same way, I can subvert attribute in any convoluted way I want
to. But that make no sens at all (and I don't expect any codebase using
such techniques to become really big).
The whole point of attaching data to a symbol via attribute is to
provide a meaning attached to that symbol. The meaning is given by the
type, like it does everywhere else.
Your MyString example or an int is a perfect example of a type that have
no meaning. Your argument is just like we shouldn't put any protection
near a precipice since people can throw themselves over it anyway. Yeah,
but at least, they'll do it on purpose and assume the consequences, and
that is a huge win.
Re: User Defined Attributes
On 11/14/2012 2:18 AM, Leandro Lucarella wrote: Can you provide one concrete case where it makes sense NOT to restrict UDAs to types One where its use is entirely inside the scope of a module, i.e. local use of it. There seems to be an assumption that UDAs are global, but I don't see a reason why that should always be true. and it's different from restricting exception to classes derived from Exception? Exceptions leak out of their scopes as an explicit part of their nature. That's the whole point of them, and I think that's the fundamental difference.
Re: User Defined Attributes
On Friday, 16 November 2012 at 13:12:34 UTC, Tove wrote:
On Friday, 16 November 2012 at 10:41:44 UTC, Walter Bright
wrote:
The whole point of my example was no, you do not necessarily
know the meaning of a user-defined type that is used as an
attribute.
Agree. Imagine we have 3 generic libs/modules...
Optimized CTFE Polygon Primitive Lib, Math, Gfx
... and then the end user, creates a program.
Both Math and Gfx, want to use the optimized Polygon in their
modules...
[Polygon(...)]
struct SpaceShip
{
}
This is just as ambiguous as if you had used a built-in
int:s... and it can be solved in the exact same way which I
outlined in the other thread.
I don't think this is a valid argument. I challenge you to find a
single real-world use case where an *annotation* would be so
complex that this would make any sense at all, yet it would be
impossible (or even just less clear) to just use a wrapper type
like @CollisionShape(Polygon(…)) or @RenderBounds(Polygon(…)).
David
Re: User Defined Attributes
On 2012-11-16 11:41, Walter Bright wrote: Sure you _can_ but it would be quite stupid. With user defined types there is at least some context. With a plain string (or any built in type) it can come from any where and mean anything. The difference is, with a user defined type you know the meaning of the attribute, with a built in type you do not, not in the same way at least. The whole point of my example was no, you do not necessarily know the meaning of a user-defined type that is used as an attribute. i don't know what to say anymore. I can only repeat what I've already said. This conversion has clearly gone into circles. -- /Jacob Carlborg
