Skip to content

Allow annotations to reference non-const objects / Meta Objects #4242

Open
@TekExplorer

Description

@TekExplorer

Now that macros arent happening, we need to focus on making build_runner better.

One of the things that makes it difficult to work with is a lack of apis on the analyzer, but thats not this issue, since one could make a package for that.

No, the issue here is meta objects.

Riverpod has to use the source objects when defining dependencies instead of the actual providers since they're not const. However, in this case, we dont actually want the provider as a value, but as code, or as a reference/meta-pointer

This is often the case, that we dont want an actual value, but non-const code.

example:

@riverpod
someDependency(ref) {...}
// generated: final someDependencyProvider;

@Riverpod(dependencies: [someDependencyProvider])
someFunction(ref) {...} 

// where
meta class Riverpod {
  const Riverpod({this.dependencies = []});
  
  // either auto const, or error as meta objects can only be const.
  Riverpod(this.dependencies);

  final List<ReferenceCode<ProviderOrFamily>> dependencies;
  // or
  final List<Pointer<ProviderOrFamily>> dependencies;
  // or
  // meta modifier only allowed in a meta class?
  final List<meta ProviderOrFamily> dependencies;
}

// non const; resolves all meta objects to "real" varients. a pointer/reference becomes the actual object, etc.
// if it cant be, then its a static error.
final nonConst = Riverpod(dependencies: [someDependencyProvider]);

// alternatively, meta modifier continues here, where it can ONLY be used in meta contexts, such as annotations or other meta classes.
meta const riverpod = Riverpod();

// this can continue into
meta import 'some_package' as metaSomething; // requires "as"?

meta class Annotation {
  Annotation([this.constructor = metaSomething.SomeClass.new]);
  final meta Function(Handle) constructor;
}

or something like that.

I know there were talks about something like that with macros, but since we're not getting macros, getting the backing features will be important.

in fact, maybe in the future we can revisit macros, once the backing features are fleshed out.

these meta objects would then have access to introspection information.
that said, it can be done incrementally. start with simple coercions into references/code and go from there

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureProposed language feature that solves one or more problems

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions