BREAKING CHANGE: #resource directive is going away

[Kasper Lund]

Dartisans,

We've decided to remove support for the #resource directive and
instead rely on metadata annotations for associating external
resources with Dart programs. I've submitted a change that removes the
support for #resource from dart2js in r11489 and the other
implementations (the VM and the analyzer) will also stop supporting
the tag in the near future.

Cheers,
Kasper

[henrichen]

Hi Kasper,

Is there any hint about what this metadata annotations would look like? And how would it be used?

/henri

[Kasper Lund]

On Fri, Aug 31, 2012 at 3:15 AM, henrichen <chen...@gmail.com> wrote:
> Is there any hint about what this metadata annotations would look like? And
> how would it be used?

I would imagine that something as simple as:

@resource("favicon.png")

could be made to work. This could then be used by deployment scripts
to make sure that those resources also get uploaded to the right
place.

Cheers,
Kasper

[Sean Eagan]

I've seen a few references to lowercase annotation names such as @deprecated, @override, and @resource, which I believe would correspond to lower case class names, which is against Dart's current style guide and Java.  I like that it's easier to type the lower case names, but isn't consistency more important?

Also, instead of repeated annotations:

@Resource("favicon.png")

@Resource("logo.png")

@Resource("sprite.png")

passing a List might make more sense:

@Resources(const ["favicon.png", "logo.png", "sprite.png"])

depending on the probability of adding more parameters to Resource beyond just the URI in the future.  Hopefully the "const" could be omitted since it's a known const context (see http://dartbug.com/4046).  Also, now that named and positional optional parameters are separated, varargs might be a possibility, and could help here:

@Resources("favicon.png", "logo.png", "sprite.png")

Cheers,

Sean

Cheers,
Kasper

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart

--
Sean Eagan

[Dirk Detering]

Am 31.08.2012 15:15 schrieb "Sean Eagan" <seane...@gmail.com>:
>
>
> I've seen a few references to lowercase annotation names such as @deprecated, @override, and @resource, which I believe would correspond to lower case class names,

Why should they?

> which is against Dart's current style guide and Java.  I like that it's easier to type the lower case names, but isn't consistency more important?
>

What consistency?  Annotations are annotations. Classes are only one (and in Dart seemingly the only) way to implement them.

> Also, instead of repeated annotations:
>
> @Resource("favicon.png")
> @Resource("logo.png")
> @Resource("sprite.png")
>
> passing a List might make more sense:
>
> @Resources(const ["favicon.png", "logo.png", "sprite.png"])
>
> depending on the probability of adding more parameters to Resource beyond just the URI in the future.  

Right. What is requested is a meta-language, kind of DSL. Unfortunately this is often confused with the implementation of the concepts in the language being annotated.
Resource may be a class, the annotation may resemble its constructor call.
But that doesn't mean that the concepts are necessarily identical. They are only made up to closely match for lack of alternative design and ease of implementation (thus the necessity for const too).

Annotations could for example be simple strings, a Lisp-like list or a JSON structure, just to name alternative representations/implementations.

[Sean Eagan]

On Wed, Sep 5, 2012 at 1:58 AM, Dirk Detering <mail...@googlemail.com> wrote:

Am 31.08.2012 15:15 schrieb "Sean Eagan" <seane...@gmail.com>:

> I've seen a few references to lowercase annotation names such as @deprecated, @override, and @resource, which I believe would correspond to lower case class names,

Why should they?

I just noticed that annotations can be "either a reference to compile-time constant variable, or a call to constant constructor". So I guess the intention is to have `deprecated` and `override` be top-level const variables. But why expose extra top-level variables when you will already be exposing Deprecated and Override classes? And what if you ever need to add an argument to the annotations? For example, it would be useful to have a link to a new method which is replacing a deprecated method:

@Deprecated(by: SomeClass.newMethod);

void oldMethod();

Also, am I correct that annotations corresponding to const constructor calls can omit "()" if not passing any arguments, which would allow for example:

@Override

void someMethod();

where Override is something like:

class Override {

  const Override();

}

Cheers,

Sean Eagan

[Brian Wilkerson]

I just noticed that annotations can be "either a reference to compile-time constant variable, or a call to constant constructor". So I guess the intention is to have `deprecated` and `override` be top-level const variables.

Correct. There is a sketch of what these two annotations might look like in .../dart/pkg/meta/meta.dart. It hasn't been added into the SDK yet because the VM doesn't yet support metadata. Once it does I expect that we'll add this library to the SDK.

But why expose extra top-level variables when you will already be exposing Deprecated and Override classes?

Actually, we weren't planning on exposing the classes. If the annotation can't have an argument, then there isn't any reason to expose the class. Using a top-level variable in this case has the advantage that you don't have to type the empty argument list.

And what if you ever need to add an argument to the annotations? For example, it would be useful to have a link to a new method which is replacing a deprecated method:

@Deprecated(by: SomeClass.newMethod);

void oldMethod();

Then we'd need to expose the class and would have to decide whether the top-level variable provided enough value to justify having two names or not. 

For what it's worth, I agree that being able to specify how references to the deprecated element (method, class, etc.) should be re-written is a very interesting idea; I just need to think about how we could provide information in a form that the tools could use.

Also, am I correct that annotations corresponding to const constructor calls can omit "()" if not passing any arguments, which would allow for example:

@Override

void someMethod();

Not as far as I can tell by looking at the specification. I think that if we exposed the class rather than a top-level variable you'd be stuck writing

@Override()

void someMethod();

If I'm wrong, then I'd be much more tempted to just expose the classes from the outset.

And as for the upper case vs. lower case question, the style guide doesn't yet address annotations. If we all agree that we like lower case names for annotations then the style guide might someday recommend using lower case even when using a class with a constant constructor.

Brian