On Mon, 03 Aug 2009 09:26:21 -0400, Don <nos...@nospam.com> wrote:
grauzone wrote:
Don wrote:
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
This looks like a solution in search of a problem. What's the problem
being solved?
Attaching additional data to types, that can't be specified
otherwhere. This should help with metaprogramming-like stuff.
For example serialization. How do you specify that a field shouldn't
be part of the serialized data? Java has an extra keyword attribute like
"transient" (comes from before attributes were introduced). C# uses
what we call annotation in this thread. How would you do this in D?
I agree that there doesn't seem to be a nice way at present. One
possibility would be to establish a naming convention for transient
fields -- a Ruby-style solution, I guess.
But are annotations actually an ideal solution for this problem?
Presumably, you'll have to specify that somewhere else anyway. I mean,
during reading it will need to either be initialized separately after
serialisation (like opPostBlit, perhaps?), or else remain uninitialized.
Serialisation seems to be _extremely_ similar to construction. I'm not
sure that annotations capture that.
Typically, items excluded from serialization are left uninitialized, or
initialized via default initializers. These types of items usually don't
make sense to restore anyways, like file handles, or cached lookup data.
D has much more powerful metaprogramming than C# or Java, so my
intuition and hope is that we shouldn't need to adopt hacks from those
weaker languages. The annotation syntax in C# and Java looks like an
ugly hack to me. Purely a subjective opinion, of course, but it seems
really out of place in a C-family language.
Annotations have more usages than just how to serialize. Some uses I've
seen in C#:
* hints to an IDE about a GUI component (what it does, what properties to
allow setting via the visual builder)
* hints to the debugger about when to skip debugging certain functions (to
avoid stepping into mundane crap such as property getters).
* hints to another program about which classes would be interesting when
dynamically loading a library
On that last one, I wrote an editor that would create xml files indicating
how to call constructors of certain types in an executable. I tagged the
types with attributes that described what they do, and how to display them
in the editor (for example, is an integer a bitmask? if so, display a set
of checkboxes with these names). Then when I would add classes to the
executable, I did not have to update the editor.
Annotations are useful in many ways, but without full reflection
capabilities, they are restricted to things that can read them via source
code, and so they are no better than comments.
-Steve
