Private members no way to implement, or is there about reflectable.dart

[sigurdm]

The problem is that the transformer cannot modify files in other packages (barback limitation dart-archive/barback#39).
So when the transformer is run on the entry-point it cannot add extra accessors to other libraries.

Can you explain more about your use-case. Maybe there is a better solution (if the fields should be manipulated from the outside they should probably not be private in the first place).

[sigurdm]

This is currently blocked on dart-archive/barback#39.
Even if this issue is solved access to private members of dart: libraries could not be implemented.
Also there are still unsolved issues with the exact mechanisms that these accesses should work by.

[eernstg]

Just making an intermediate assumption explicit: Jake, it sounds like you have a package P, that package contains some private declarations, say, including C._x, and you want to enable clients (that is, some other package Pc that uses P by having it in its 'dependencies:' in 'pubspec.yaml') to access C._x using reflectable-based reflection?

In that case you'd need the cross-package transformation feature that Sigurd mentioned (and in that case I'm also tempted to ask why such a "semantically public" feature would need to be technically private).

However, if you want to use the reflectable transformer inside your package P, and the issue is that some libraries in P need to access private declarations in other libraries in P, then it would be sufficient if reflectable could access private features inside the same package. That would not be impossible, but it would require a non-trivial amount of refactoring (so with the current version of reflectable it is impossible, and if we decide that we want to add this feature then it still needs to be done).

[jrote1]

@sigurdm @eernstg Sorry seems I wasn't clear I kind of wrote the issue quite quick. I was suggesting a way it could be accomplished in this project based on my prior experience.

[eernstg]

You could certainly write some accessor proxies in the library that contains the private declarations (e.g., if class C has a private member int _x then you could use a top-level function like int getC_x(C c) => c._x; and a similar putC_x to provide non-private access to it). That kind of techniques might solve an acute problem if it does not get out of hand, and it might even be useful to generate the code. But in a more general setting we must consider access to private features as an unsolved problem in reflectable.

[HerrNiklasRaab]

Is there any progress to expect on this issue?

[eernstg]

Dart privacy is a hard protection (that is, there is no way to circumvent it in a Dart program), and reflectable relies on generated code (so execution can only do things that a Dart program can do), so the lack of support for access to private declarations is a hard limitation. So, unfortunately, there is no progress.

[HerrNiklasRaab]

Ok, so if understand correctly, dart would need a capability like:

class Test {
   bool _private = false;
}

var accessPrivate = AllowPrivateAccess(Test());
accessPrivate._private = true; // Possible

Would it make sense to open an issue on dart/language? The above example is obviously very dangerous, but maybe we could collect ideas on how to tackle this?

Is there any cause why this isn't closed?

[eernstg]

There have been various discussions about privacy in the language repo. I don't think there is one specifically about allowing privacy to be violated in regular Dart code.

This issue has been kept open for a couple of reasons. One is that we used to consider different code generation schemes. In particular, if reflectable were to generate a part for each library containing declarations which are covered by reflection capabilities then it could use private names from that library. However, that doesn't scale to the situation where we wish to reflect on declarations in third party libraries (we can't force those libraries to use these parts) or system libraries (we certainly can't add code to 'dart:core' and such).

Another possibility is that developers could provide hooks (e.g., (MyType x) => x._somePrivateGetter), and there should then be a way for reflectable to receive information about specific hooks, solving specific privacy related tasks.

However, there are no concrete plans to add such hooks. So I'll close the issue. It will still serve as a location where we can get information about why this restriction exists.