The problem is that the emitting code doesn't see accessors as
functions, so it doesn't assign a null function to the member. I'm
working on a fix.
EdB
On Thu, Dec 5, 2013 at 8:45 PM, Alex Harui <aha...@adobe.com> wrote:
> IMO, there are hand-coded interfaces and cross-compiled interfaces. It
> isn't clear that cross-compiled interfaces need their insides since they
> are guaranteed to be equivalent, but I do agree that hand-coded ones
> should so they can be checked by the JS tool chain.
>
> Or am I missing something?
>
> I don't think I'm as familiar with dealing with these closure compiler
> warnings as you are. If you have the cycles to cross-compile the
> interface I posted you can undo the one change I made and see the results
> yourself and fix or advise on a fix, that would help a lot.
>
> Thanks,
> -Alex
>
> On 12/5/13 11:37 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>
>>If we aim to make both sides of the equation equal (AS framework API
>>matches JS framework API) we can assume a lot more than that:
>>basically, all type checking would already have been done by the AS
>>compiler.
>>
>>But, as you have indicated repeatedly, this equality will never
>>happen. So, given that the APIs cannot be assumed to be equal, I think
>>we should use all the help we can get from the JS compiler to catch
>>errors and incorrect assumptions.
>>
>>Most of the warnings the JS compiler threw before we got rid of them
>>seemed 'ignorable' at first glance, but it turned out they were a
>>symptom of something deeper: the deps calculation wasn't working
>>properly. This makes me think that the 'unused getprop' either is the
>>result of a very simple oversight (type check missing, or some such),
>>or that it indicates something wrong with one of the frameworks. Maybe
>>killing the proximate reason for the warning won't fix the ultimate
>>problem...
>>
>>EdB
>>
>>
>>
>>On Thu, Dec 5, 2013 at 7:48 PM, Alex Harui <aha...@adobe.com> wrote:
>>> Something about "unused getprop" or something like that?
>>>
>>> Wondering though: Are you sure we need the compiler to do this check?
>>> Can't we assume the AS compiler has already done this sort of check?
>>> Would we save a few bytes by not actually generating the insides of
>>> cross-compiled interfaces?
>>>
>>> -Alex
>>>
>>> On 12/5/13 10:12 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>>>
>>>>Which warning did you get from the compiler?
>>>>
>>>>EdB
>>>>
>>>>
>>>>
>>>>On Thu, Dec 5, 2013 at 6:36 PM, Alex Harui <aha...@adobe.com> wrote:
>>>>> OK, can you give more details on what it is checking for?
>>>>>
>>>>> For the AS interface:
>>>>>
>>>>> public interface IDataProviderItemRendererMapper extends IBead
>>>>> {
>>>>> function get itemRendererFactory():IItemRendererClassFactory;
>>>>> function set
>>>>>itemRendererFactory(value:IItemRendererClassFactory):void;
>>>>> }
>>>>>
>>>>> What should the output JS be? What it was doing (from emitInterface
>>>>>in
>>>>> JSGoogEmitter.java) was resulting in warnings from the closure
>>>>>compiler.
>>>>> The output was the following and the itemRendererFactory line
>>>>>resulting
>>>>>in
>>>>> a warning.
>>>>>
>>>>> /**
>>>>> *
>>>>>
>>>>>org.apache.flex.html.customControls.beads.IDataProviderItemRendererMapp
>>>>>er
>>>>> *
>>>>> * @fileoverview
>>>>> *
>>>>> * @suppress {checkTypes}
>>>>> */
>>>>>
>>>>>
>>>>>goog.provide('org.apache.flex.html.customControls.beads.IDataProviderIt
>>>>>em
>>>>>Re
>>>>> ndererMapper');
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> /**
>>>>> * @interface
>>>>> * @extends {org.apache.flex.core.IBead}
>>>>> */
>>>>>
>>>>>org.apache.flex.html.customControls.beads.IDataProviderItemRendererMapp
>>>>>er
>>>>> = function() {
>>>>> };
>>>>>
>>>>>org.apache.flex.html.customControls.beads.prototype.itemRendererFactory
>>>>>;
>>>>>
>>>>>
>>>>> /**
>>>>> * Metadata
>>>>> *
>>>>> * @type {Object.<string, Array.<Object>>}
>>>>> */
>>>>>
>>>>>org.apache.flex.html.customControls.beads.IDataProviderItemRendererMapp
>>>>>er
>>>>>.p
>>>>> rototype.FLEXJS_CLASS_INFO = { names: [{ name:
>>>>> 'IDataProviderItemRendererMapper', qName:
>>>>>
>>>>>'org.apache.flex.html.customControls.beads.IDataProviderItemRendererMap
>>>>>pe
>>>>>r'
>>>>> }], interfaces: [org.apache.flex.core.IBead] };
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/4/13 11:55 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>>>>>
>>>>>>The Closure Compiler uses the members of an interface to check if the
>>>>>>interface is properly implemented. So, yes, I'd say we need the
>>>>>>members emitted...
>>>>>>
>>>>>>EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>>On Thu, Dec 5, 2013 at 7:12 AM, <aha...@apache.org> wrote:
>>>>>>> Don't bother emitting interface members. The way they were being
>>>>>>>emitted were causing warnings from the closure compiler
>>>>>>>
>>>>>>>
>>>>>>> Project: http://git-wip-us.apache.org/repos/asf/flex-falcon/repo
>>>>>>> Commit:
>>>>>>>http://git-wip-us.apache.org/repos/asf/flex-falcon/commit/70683e5d
>>>>>>> Tree:
>>>>>>>http://git-wip-us.apache.org/repos/asf/flex-falcon/tree/70683e5d
>>>>>>> Diff:
>>>>>>>http://git-wip-us.apache.org/repos/asf/flex-falcon/diff/70683e5d
>>>>>>>
>>>>>>> Branch: refs/heads/develop
>>>>>>> Commit: 70683e5d223538713c02eb02029f4e67686c0c7a
>>>>>>> Parents: 30fd603
>>>>>>> Author: Alex Harui <aha...@apache.org>
>>>>>>> Authored: Wed Dec 4 22:11:39 2013 -0800
>>>>>>> Committer: Alex Harui <aha...@apache.org>
>>>>>>> Committed: Wed Dec 4 22:11:39 2013 -0800
>>>>>>>
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>-
>>>>>>> .../codegen/js/flexjs/JSFlexJSEmitter.java | 65
>>>>>>>++++++++++++++++++++
>>>>>>> 1 file changed, 65 insertions(+)
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>http://git-wip-us.apache.org/repos/asf/flex-falcon/blob/70683e5d/comp
>>>>>>>il
>>>>>>>er
>>>>>>>.jx/src/org/apache/flex/compiler/internal/codegen/js/flexjs/JSFlexJSE
>>>>>>>mi
>>>>>>>tt
>>>>>>>er.java
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>-
>>>>>>> diff --git
>>>>>>>a/compiler.jx/src/org/apache/flex/compiler/internal/codegen/js/flexjs
>>>>>>>/J
>>>>>>>SF
>>>>>>>lexJSEmitter.java
>>>>>>>b/compiler.jx/src/org/apache/flex/compiler/internal/codegen/js/flexjs
>>>>>>>/J
>>>>>>>SF
>>>>>>>lexJSEmitter.java
>>>>>>> index a65335d..cd67c00 100644
>>>>>>> ---
>>>>>>>a/compiler.jx/src/org/apache/flex/compiler/internal/codegen/js/flexjs
>>>>>>>/J
>>>>>>>SF
>>>>>>>lexJSEmitter.java
>>>>>>> +++
>>>>>>>b/compiler.jx/src/org/apache/flex/compiler/internal/codegen/js/flexjs
>>>>>>>/J
>>>>>>>SF
>>>>>>>lexJSEmitter.java
>>>>>>> @@ -197,6 +197,71 @@ public class JSFlexJSEmitter extends
>>>>>>>JSGoogEmitter
>>>>>>>implements IJSFlexJSEmitter
>>>>>>> }
>>>>>>>
>>>>>>> @Override
>>>>>>> + public void emitInterface(IInterfaceNode node)
>>>>>>> + {
>>>>>>> + ICompilerProject project = getWalker().getProject();
>>>>>>> +
>>>>>>> + getDoc().emitInterfaceDoc(node, project);
>>>>>>> +
>>>>>>> + String qname = node.getQualifiedName();
>>>>>>> + if (qname != null && !qname.equals(""))
>>>>>>> + {
>>>>>>> + write(qname);
>>>>>>> + write(ASEmitterTokens.SPACE);
>>>>>>> + writeToken(ASEmitterTokens.EQUAL);
>>>>>>> + write(ASEmitterTokens.FUNCTION);
>>>>>>> + write(ASEmitterTokens.PAREN_OPEN);
>>>>>>> + write(ASEmitterTokens.PAREN_CLOSE);
>>>>>>> + write(ASEmitterTokens.SPACE);
>>>>>>> + write(ASEmitterTokens.BLOCK_OPEN);
>>>>>>> + writeNewline();
>>>>>>> + write(ASEmitterTokens.BLOCK_CLOSE);
>>>>>>> + write(ASEmitterTokens.SEMICOLON);
>>>>>>> + }
>>>>>>> +
>>>>>>> +
>>>>>>> + /* (aharui): is there any reason to emit members at all?
>>>>>>> + final IDefinitionNode[] members =
>>>>>>>node.getAllMemberDefinitionNodes();
>>>>>>> + for (IDefinitionNode mnode : members)
>>>>>>> + {
>>>>>>> + boolean isAccessor = mnode.getNodeID() ==
>>>>>>>ASTNodeID.GetterID
>>>>>>> + || mnode.getNodeID() == ASTNodeID.SetterID;
>>>>>>> +
>>>>>>> + if (!isAccessor || !propertyNames.contains(qname))
>>>>>>> + {
>>>>>>> + writeNewline();
>>>>>>> +
>>>>>>> + write(qname);
>>>>>>> + write(ASEmitterTokens.MEMBER_ACCESS);
>>>>>>> + write(JSEmitterTokens.PROTOTYPE);
>>>>>>> + write(ASEmitterTokens.MEMBER_ACCESS);
>>>>>>> + write(mnode.getQualifiedName());
>>>>>>> +
>>>>>>> + if (isAccessor && !propertyNames.contains(qname))
>>>>>>> + {
>>>>>>> + propertyNames.add(qname);
>>>>>>> + }
>>>>>>> + else
>>>>>>> + {
>>>>>>> + write(ASEmitterTokens.SPACE);
>>>>>>> + writeToken(ASEmitterTokens.EQUAL);
>>>>>>> + write(ASEmitterTokens.FUNCTION);
>>>>>>> +
>>>>>>> + emitParameters(((IFunctionNode)
>>>>>>>mnode).getParameterNodes());
>>>>>>> +
>>>>>>> + write(ASEmitterTokens.SPACE);
>>>>>>> + write(ASEmitterTokens.BLOCK_OPEN);
>>>>>>> + writeNewline();
>>>>>>> + write(ASEmitterTokens.BLOCK_CLOSE);
>>>>>>> + }
>>>>>>> +
>>>>>>> + write(ASEmitterTokens.SEMICOLON);
>>>>>>> + }
>>>>>>> + }
>>>>>>> + */
>>>>>>> + }
>>>>>>> +
>>>>>>> + @Override
>>>>>>> public void emitField(IVariableNode node)
>>>>>>> {
>>>>>>> IDefinition definition = getClassDefinition(node);
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>Ix Multimedia Software
>>>>>>
>>>>>>Jan Luykenstraat 27
>>>>>>3521 VB Utrecht
>>>>>>
>>>>>>T. 06-51952295
>>>>>>I. www.ixsoftware.nl
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>Ix Multimedia Software
>>>>
>>>>Jan Luykenstraat 27
>>>>3521 VB Utrecht
>>>>
>>>>T. 06-51952295
>>>>I. www.ixsoftware.nl
>>>
>>
>>
>>
>>--
>>Ix Multimedia Software
>>
>>Jan Luykenstraat 27
>>3521 VB Utrecht
>>
>>T. 06-51952295
>>I. www.ixsoftware.nl
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
