overwriting methods with custom namespaces

[oopstoons]

Can methods declared with a custom namespace be overwritten?

// secret.as
package {
   public namespace secret = "http://www.example.com/secret";
}

// Base.as
package {
   import secret;
   public class Base {
      public function Base() {
      }

      secret function test():void {
         trace("Base test");
      }
   }
}

// Extended.as
package {
   import secret;
   public class Extended extends Base {
      public function Extended() {
      }

      override secret function test():void {
         trace("Extended test2");
      }
   }
}

If I try the above I get "1004: Namespace was not found or is not a compile-time constant."
If I remove override I get "VerifyError: Error #1053: Illegal override of test in Extended."
Is this not possible? Is there a workaround? Thanks.

[IqAndreas]

Does it make a difference if you write (in this order)
secret override function ...

Otherwise, I'm looking into it, and will get back to you if I find a fix.

[oopstoons]

Unfortunately the order did not matter. Do you know if there is a way to make that namespace definition a compile-time constant?

[IqAndreas]

Is that exactly how your code is written out when you tested it? Or is it just a stripped down version? If not, I am 98% sure that there is a small typo somewhere.

I can't see any reason whatsoever why the code won't work. The way you are defining it should automatically cause it to become a compile-time constant.

Try replacing "secret" with "public" to see if it at least works. If it still gives errors, at least you will know that it is likely not caused by the namespace.

I would also try doing something like "trace(secret)" and seeing what it returns.

[wvxvw]

Hi, namespaces are resolved by their URI, so, if you know, what is the URI value, you can declare a namespace inside your other class and use that declaration, you don't have to import anything.
I.e.:

public namespace foo = "flash.display";
// and
public namespace foobar = "flash.display";
// will target the same object
trace(foo::["MovieClip"], foobar::["MovieClip"]);
// [class MovieClip] [class MovieClip]

[oopstoons]

Originally Posted by IqAndreas

Is that exactly how your code is written out when you tested it? Or is it just a stripped down version?

Exact code. Testing small case to isolate the bugs.

[oopstoons]

Ok, I got rid of the namespace class and instead explicitly declared the namespace in both my Base and Extended classes. This worked! Thanks.

// Base.as
 package {
     public class Base {
         private namespace secret = "http://www.example.com/secret";
         
         public function Base() {
         }
 
         secret function test():void {
             trace("Base test");
         }
     }
 }
 
 // Extended.as
 package {
     public class Extended extends Base {
         private namespace secret = "http://www.example.com/secret";
         
         public function Extended() {
         }
 
         override secret function test():void {
             trace("Extended test2");
         }
     }
 }

I don't really see much use in creating classes only for defining namespaces if they don't work with something as core as overriding methods. I thought I was following best practices by only defining the namespace once. I guess not. Thanks again!

[wvxvw]

oopstoons:
No-no-no-no, you were thinking correctly, and, actually, that what should've happen, but, practically it doesn't happen like that all the time... some compiler quirks. Could be that in next version of compiler it will get fixed, or, maybe it's already fixed and you just have to get that new version. I think it inconsistently happened to me now and then, so, I "discovered" this workaround, but, normally, you shouldn't be needing it.

[oopstoons]

I understand. Thanks for helping me "discover" this workaround. You wouldn't happen to know how to mark classes to compile as compile-time constants would you? I assume if you did, you wouldn't need this workaround.

[wvxvw]

Not unless you make a preprocessor Which I'm into right now sort of... but no, you cannot make a class into a compile time constant, although there is sort of conditional compilation in MXMLC, which has sort of possibility to define sort of compiler constants, but, oh well...