search

aaron-nance / as3-commons

Automatically exported from code.google.com/p/as3-commons
0 stars 0 forks source link

PropertyBuilder.buildPropertyInitializers fails when namespaceURI and memberInitialization is set #68

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Create a new PropertyBuilder on ClassBuilder.defineProperty
2. Set PropertyBuilder.namespaceURI to as3commons_bytecode_proxy
3. Set PropertyBuilder.memberInitialization to new MemberInitialization
4. Build and load class
5. Instantiate new class

What is the expected output? What do you see instead?
ReferenceError: Error #1056: Cannot create property {PROPERTY_NAME} on 
{CLASS_NAME}.

What version of the product are you using? On what operating system?
1.0RC5 on MacOSX 10.7

Please provide any additional information below.
Issue appears to be with PropertyBuilder.createPropertyQualifiedName, if I 
check for presence of namespaceURI and return new QualifiedName(name, new 
LNamespace(NamespaceKind.NAMESPACE, namespaceURI)), it works properly.

Original issue reported on code.google.com by jeff.ard...@gmail.com on 10 Aug 2011 at 4:49

GoogleCodeExporter commented 8 years ago 
Forgot that there was also 1 related change to 
PropertyBuilder.createPropertyTypeQualifiedName. By default, it attempts to 
create a new qualified name with the namespace kind defined by the properties 
visibility. In this instance, it tried to create the type qualified name with a 
namespace kind of NAMESPACE, instead of what should be PACKAGE_NAMESPACE, thus 
throwing an error:

ReferenceError: Error #1065: Variable 
{TYPE_PACKAGE_NAME}:{TYPE_CLASS_NAME}::{TYPE_CLASS_NAME} is not defined.

Adding a check for namespaceURI and changing the namespace kind resolves this 
issue:

MultinameUtil.toQualifiedName(_type, NamespaceKind.PACKAGE_NAMESPACE)

Original comment by jeff.ard...@gmail.com on 10 Aug 2011 at 5:09

GoogleCodeExporter commented 8 years ago 
Hi there,

I believe I managed to fix this, custom namespaces were indeed to taken into 
account when generating the opcodes for member initialization.
Changes are available in the trunk, I created a unit test for this particular 
situation, if you can confirm that the fix also works correctly for you then I 
can close this issue.

Thanks a lot for bringing this bug ot my attention!

cheers!

Roland

Original comment by ihatelivelyids on 10 Aug 2011 at 7:11

GoogleCodeExporter commented 8 years ago 
That works for me, thanks for the quick turn around!

Original comment by jeff.ard...@gmail.com on 10 Aug 2011 at 7:57

GoogleCodeExporter commented 8 years ago 
great, thanks for the confirmation!

Original comment by ihatelivelyids on 10 Aug 2011 at 7:59