-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reflection #57
Comments
One humble suggestion for sparking the discussion: To ease the step to getting a reflection API up and running for pony, maybe it is worth to get things started with a really basic version that is only able to output the type name of a class. It might be implemented as some kind of An example API // example with type method generated for every class/primitive
let myStringRef: (Stringable & ByteSeq) = "abc"
let type: Type = myStringRef.type()
let typeName = type.name() // "String"
// example with Reflection primitive
let myRefWithTypeParams: Array[String] = ["abc"; "def"]
let type: Type = Reflection.type(myRefWithTypeParams)
let typeName = type.name() // "Array[String]" Getting the type from an object reference might not need to involve any capability checking or Auth as long as the type is as simple as outlined above. Such a trait Type
fun name(): String
fun traits(): Seq[Type]
fun interfaces(): Seq[Type] Given that this is very barebones, i think it is necessary to make sure that its design doesn't contradict with the vision of the full reflection API. So it will be easy to just extend the given types and methods without breaking changes if possible. |
I think that the first step is an Introspection API, rather than the full-fledged Reflection system found in Java and elsewhere, where you can modify values willy-nilly which will violate compiler type/data-race safety. And perhaps reading values are also left out for that reason, but calling behaviors and constructors should be ok (I think). IF (this part is unclear to me atm) there is only a "compile all from source" option, i.e. no libraries, then the compiler can determine (by encountering call to I would like to propose a little bit more of "barebones" than @mfelsche above. Since I am not at all proficient in Pony yet, I am sure there are many things that I have misunderstood, so please bear with me, but I think it is a reasonable starting point from someone who has extensive experience with reflection in Java (all the way back to when Reflection API was introduced in Java 1.1 (1997)) I don't think we should burden all types with I think(!) the stuff below is not inflicting complications on the type system guarantees, as only behaviors can be invoked and constructors to be called.
|
I don't much like the idea of having traits/interfaces that you have to opt into. I'm also not a fan of segmenting off a large chunk of namespacing like It would result in a lot of code breakage. On a user API side, I'd rather see some combination of primitives that can be passed Pony objects like instances of a class, actor, etc and extract information from it via something that I think would be using a c-api to hooked into information generated at compile time. |
I think you must be missing something important....
One calls the Introspection API to obtain an object (and transitively other
objects) that fulfill these traits. They are NOT part of regular objects...
I even pointed out that unlike Java's Object.getClass() I am proposing that
no such "namespace intruding" function is placed on types, but that a
function in the API itself is the "entrypoint", so that no compatibility
issues should exist with existing codebases.
…On Wed, Aug 28, 2019, 21:12 Sean T Allen ***@***.***> wrote:
I don't much like the idea of having traits/interfaces that you have to
opt into. I'm also not a fan of segmenting off a large chunk of namespacing
like name where no class can have name as a method because it would
conflict with reflection/introspection.
It would result in a lot of code breakage.
On a user API side, I'd rather see some combination of primitives that can
be passed Pony objects like instances of a class, actor, etc and extract
information from it via something that I think would be using a c-api to
hooked into information generated at compile time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#57?email_source=notifications&email_token=AAA2BROUBA2LUILRWEPGVBLQGZ2SBA5CNFSM4CTXPXKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5LCFJI#issuecomment-525738661>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAA2BRLS7YP7RXYQPJ5B3VTQGZ2SBANCNFSM4CTXPXKA>
.
|
@niclash what would implement these traits that you propose? Perhaps I was mislead by your usage of |
That's an implementation detail...
I imagine those traits are actually classes.
…On Wed, Aug 28, 2019, 23:35 Sean T Allen ***@***.***> wrote:
@niclash <https://github.com/niclash> what would implement these traits
that you propose?
Perhaps I was mislead by your usage of trait in your example and that
wasn't what you were intending.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#57?email_source=notifications&email_token=AAA2BRLCTRYIKJ4M7PLRRETQG2LMZA5CNFSM4CTXPXKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5LRG5I#issuecomment-525800309>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAA2BRKHM5WOJMVYZM4RDLLQG2LMZANCNFSM4CTXPXKA>
.
|
This is the new home of the ponyc issue 87.
If you'd like to take on writing this RFC, we'd welcome working with you.
The text was updated successfully, but these errors were encountered: