Annotation case

[Sébastien Deleuze]

Hi,

As discussed on https://groups.google.com/a/dartlang.org/d/msg/web-ui/iaErCRjLozU/iuYA-36hkEEJ I find very confusing that some annotations begin by a upper-case first letter (@CustomTag for example), and some other like @observable or @deprecated by a lower-case letter. In understand the answer of John (annotations could be constant or classes), but from a user point of view, I find this very disturbing and confusing.

Why not allowing defining annotations only with classes not const, it would be more extensible, consistent and less confusing ?

Regards,

Sébastien

[Alexander Voronin]

As I understood all discussions about metadata  (here for example) it's just a google's vision of implementation. Also I'd like to have mutable metadata in dart like in c# ind java. But seems there's no way to affect or change this :)

2013/9/2 Sébastien Deleuze <bou...@gmail.com>

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
когда я опустился на самое дно, снизу мне постучали..

[Sébastien Deleuze]

I understand, but I can try ;-)

Mutable metadata would have a performance impact, my proposal would'nt ;-)

Also, reading the code of Dart annotation definition like in meta.dart make me feel that const annotations are just here to avoid unpleasant empty parenthesis for annotations without parameters ...

const deprecated = const _Deprecated();

class _Deprecated {
  const _Deprecated();
}

[Filipe Morgado]

From what I understood, const classes (with same arguments) always resolve to the same instances.

So, if we have

class MyMetadata {
  const  MyMetadata();
}

 and we use it twice

@MyMetadata
var myVar1;
@MyMetadata
var myVar2;

The same instance will be used, as if ...

const MY_METADATA = const MyMetadata();

was implicitly declared and used twice.

I like the way metadata is implemented currently, even if with some rough edges.

If it was mutable, I guess it would have to be instantiated every time it's accessed.

Except for the mirroring stuff, which I find easier to use, metadata in Dart is pretty close to AS3 (didn't use metadata in other languages).

So I don't think it's a "Google-only way to do it".

I would find one thing very useful ... to be able to initialize final fields in the constructors, so metadata could do some parsing before setting its constant state.

[Sébastien Deleuze]

As I said before, I don't want Mutable annotations, I would like less confusing annotations from a user POV.

One concrete example of what I was talking about, Dice (http://pub.dartlang.org/packages/dice) now supports @Named annotation

class MyClass {
 @inject
 @Named('my-special-implementation')
 SomeClass _someClass;
}

I don't really find the lowercase @inject + uppercase @Named nice, especially used together ...

[Bob Nystrom]

This is confusing. I'll try to talk to some people on the team and figure out what the plan is here. Annotations kind of appeared spontaneously in the language spec without any discussion of style or how they should be used in practice, or at least not any discussions where I could hear them.

Cheers!

- bob

--

[Lasse R.H. Nielsen]

We should also have guidelines for how to *interpret* annotations.

Since annotations are values, they should generally be treated as such. 

const foo = const Foo();

@foo 

int bar() => 42;

@Foo()

int bar2() => 42;

The annotations here look different, but are the same object. An annotation processor should probably consider them the same object, and different from another library which does:

const foo = const Bar();

@foo

int bif() => 42;

That's another "foo" entirely.

We currently have the problem with @deprecated, where we haven't made a general declaration that users can use, so instead we are doing 

  const deprecated = 1;

  

  @deprecated

  int dontUseThis() => 42;

and expecting the editor to do syntactic comparison instead of semantic comparison.

/L 'Just extend DartDoc with @deprecated if you want syntactic comparison'.

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Sean Eagan]

I filed a bug on this, to allow @Foo as shorthand for @Foo(), which removes the need for @foo:

http://dartbug.com/13582

Cheers,
Sean Eagan

[Sébastien Deleuze]

+1 for this solution, I hope this annotation specific shorthand will be accepted.

[George Moschovitis]

+10

[Sean Eagan]

On Wed, Sep 25, 2013 at 12:02 PM, Sean Eagan <seane...@gmail.com> wrote:

I filed a bug on this, to allow @Foo as shorthand for @Foo(), which removes the need for @foo:

http://dartbug.com/13582

So, there is a competing bug to allow runtimeType literals as annotation values:

http://dartbug.com/11857

For example, in...

@MyAnnotation

var foo;

... the metadata value will be interpreted as the class itself `MyAnnotation` instead of an instance of the class `const MyAnnotation()`.

I can't think of any use cases for this, or similar functionality in other languages, and it seems quite error prone for people coming from Java/C#/etc where it's interpreted as an instance.  I posted a question in the bug, but maybe someone here has an idea?

Cheers,

Sean Eagan

[John Messerly]

The thing to the right of @ is just a constant expression, the only magic is it saves you from writing the "const" keyword (since you already have the "@" there). A type-literal should be valid expression there. Similarly in arguments:

@foo(SomeType)

Anyway, if bug 11857 was fixed, it would be easy to have code that checks for both:

for (var metadataMirror in mirror.metadata) {

  var meta = metadataMirror.reflectee;

  // Check for @MyAnnotation or @MyAnnotation(some,args)

  if (meta == MyAnnotation || meta is MyAnnotation) {

    ... do stuff ...

  }

}

From using metadata more in Polymer.dart, I'm kinda leaning towards uppercase names, to avoid conflicting with the (crowded) camelCase namespace.

[Sean Eagan]

On Thu, Oct 3, 2013 at 5:33 PM, John Messerly <jmes...@google.com> wrote:

On Thu, Oct 3, 2013 at 2:27 PM, Sean Eagan <seane...@gmail.com> wrote:

On Wed, Sep 25, 2013 at 12:02 PM, Sean Eagan <seane...@gmail.com> wrote:

I filed a bug on this, to allow @Foo as shorthand for @Foo(), which removes the need for @foo:

http://dartbug.com/13582

So, there is a competing bug to allow runtimeType literals as annotation values:

http://dartbug.com/11857

For example, in...

@MyAnnotation

var foo;

... the metadata value will be interpreted as the class itself `MyAnnotation` instead of an instance of the class `const MyAnnotation()`.

I can't think of any use cases for this, or similar functionality in other languages, and it seems quite error prone for people coming from Java/C#/etc where it's interpreted as an instance.  I posted a question in the bug, but maybe someone here has an idea?

The thing to the right of @ is just a constant expression

Not an arbitrary constant expression, spec. only allows:

1) A reference to a compile-time constant variable.

2) The name of a class.

3) A call to a constant constructor.

, the only magic is it saves you from writing the "const" keyword (since you already have the "@" there).

yes, in case 3) only

A type-literal should be valid expression there.

Why?  The metadata syntax does not allow arbitrary constant expressions.  And 3) is already syntactically irregular with normal dart syntax by omitting the "const " prefix.  I don't see how omitting the "()" suffix is any less useful, for both convenience and familiarity (with Java/C#).  And I also don't see what value 2) adds to what we already have with 3).

Anyway, if bug 11857 was fixed, it would be easy to have code that checks for both:

for (var metadataMirror in mirror.metadata) {

  var meta = metadataMirror.reflectee;

  // Check for @MyAnnotation or @MyAnnotation(some,args)

  if (meta == MyAnnotation || meta is MyAnnotation) {

That seems strictly worse than only having to check `meta is MyAnnotation`, and semantically irregular.

If the MyAnnotation constructor has required arguments, then `@MyAnnotation` doesn't make any sense, but the user will type this, and will be given no error ( due to 2) ), and will thus assume that no arguments are needed.   The `meta is MyAnnotation` also wouldn't make sense in this case, so the metadata consuming code will have to aware of whether the annotation constructor it's reflecting on has required arguments.

Also, what if someone subclasses MyAnnotation with TheirAnnotation, and uses it via `@TheirAnnotation`, then the if statement above returns false, when we want it to return true.

From using metadata more in Polymer.dart, I'm kinda leaning towards uppercase names, to avoid conflicting with the (crowded) camelCase namespace.

I agree with using the class name, but it should be interpreted as a class instance, not the class itself.

Also, the style guide would require them to be UPPER_UNDERSCORE_SEPARATED, not camelCase, since they are constant variables.

Cheers,

Sean