>For the patch mentioned below, will you apply that to develop? Or do you
>want me to do that sometime tomorrow?
Now that you are a committer, you can do it yourself!
I will! Will do that later today. :)
What do you mean by "pure". That it is a direct result of the parsing?
We don't have to finish this discussion now, I just want to stick in the
back of my head for a while.
I guess it is easier to describe it in terms of my personal analogy (which
as I said, may not apply in compiler-land in general, or specifically here)
If the Typed defintion representation of the AST is like the vector data in
a displayobject, then, I am thinking of [Bindable]'s implicit
implementation as possibly more like a Matrix or ColorTransform
Perhaps there is a way to do something like this already in the compiler
code and I just have not discovered it yet. iirc I think I did see some
'isImplicit()' methods.
Vaguely, I am thinking sort of like:
IDefintion {
extras:
Boolean isTransformed() //might be useful to know that this is 'virtual'
Boolean getHasTransforms()
IDefintion getTransformedDefintion()
set/clear transforms support methods etc... IDefinitionTransformer
}
IDefinitionTransformer { //e.g. [Bindable] on class or [Bindable] on var
Boolean isApplicableFor(IDefinition dev); //then add it to the collection
above (e.g. check if the class definition has 'Bindable')
void applyTo(IDefintion proxyDefinition); //called in sequence inside
getTransformedDefintion()
above
}
example:
definitionForOutput = class_defintion.getHasTransforms() ?
class_defintion. getTransformedDefintion()
: class_defintion;
getHasTransforms would create a proxy clone of the original definition and
then apply the transforms and cache the result for subsequent requests.
If the doc emitters are also driven from the type definitions (I think they
are?), then the above approach might permit docgen from the transformed
definitions as well.
But probably none of this really makes sense unless:
a) we can conceive of a scenario where one pass of the AST can result in
multiple outputs with different variations of transformed output
(transforms would be changed between outputs)
and/or
b) we want to make metadata-driven (or possibly other types of) output
transformations extensible
As I think you pointed out, Bindable (convenience) implementations would
only be an easy candidate for 'swappable' (e.g. for as3 signal based
implementation etc) if there were no explicit implementations of
getters/setters elsewhere in the project.
None of this is something I specifically 'want', it's just my mind
wandering. I should stop my ponderings here :) None of this may be relevant
- if you think it is useful to revisit, as you said, we can do so later.
On Thu, Sep 8, 2016 at 4:37 AM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 9/7/16, 1:11 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >I can see advantages either way, but had assumed that longer term it may
> >be
> >advantageous to keep the AST/Typed AST more 'pure'
>
> What do you mean by "pure". That it is a direct result of the parsing?
> We don't have to finish this discussion now, I just want to stick in the
> back of my head for a while.
>
> >
> >Re : "It is a convenience feature: the compiler could just report an error
> >saying you can't use [Bindable] on Objects."
> >I guess that is always another option. :)
> >[Bindable] implicit implementation was many times overused by some Flex
> >developers in the past, I was probably guilty of this myself in the early
> >days. But it is quite handy and quick sometimes, so long as you know the
> >implications of its use/abuse. And if it is taken away now I am pretty
> >sure
> >sdk users will ask for it back ;)
>
> I wouldn't take away the [Bindable] on Objects feature, I was just
> pointing out that it really is a shortcut to writing the proper source
> code. If I could, I would actually have the compiler alter the source
> file. Otherwise, imagine how surprised you are when you see a call to
> super() or debug into super() and it doesn't go to Object.
>
> IMO, implementing [Bindable] by hacking the AST is sort of like having a
> preprocessor phase (which the former Falcon engineers were very much
> against). I still ponder the notion of metadata-as-macros and having
> [Bindable] be one of them.
>
> >
> >For the patch mentioned below, will you apply that to develop? Or do you
> >want me to do that sometime tomorrow?
>
> Now that you are a committer, you can do it yourself!
>
> -Alex
>
>
