The forums have permanently moved to forum.kirupa.com. This forum will be kept around in read-only mode for archival purposes. To learn how to continue using your existing account on the new forums, check out this thread.


Results 1 to 12 of 12

Thread: Overriding and Protecting the Super Public Methods

  1. #1

    Fla Script Overriding and Protecting the Super Public Methods

    Hi there.

    I was wandering if one super public method, overrided by an implementation class could be somewhat protected by that implementation class, in a way that only by extending that implementation class one developer could execute.

    Kinda tricky, eh?! So I'll provide an example:

    I have the Timer Class as a superclass of my MyTimer Class. MyTimer overrides the 'reset' method to provide additional functionalities. But I want to seal MyTimer completely, in a way that it will only work as 'Super' for other set of timer classes that many people will build.
    So, in that example, I'm actually looking for a way to protect one super public class.

    Is it possible? :S

  2. #2
    1,596
    posts
    Holosuite User
    Not sure I'm getting your idea... but you can mark methods as final, if this is what yo want... this will prevent extending classes from overriding it, but they will still be visible to them.

    like this:
    Code:
    package  
    {
    	import flash.utils.Timer;
    	
    	/**
    	* MyTymer class.
    	* @author wvxvw
    	*/
    	public class MyTymer extends Timer
    	{
    		
    		public function MyTymer(delay:uint, count:uint = 0) 
    		{
    			super(delay, count);
    		}
    		
    		private function doMyStuff():void
    		{
    			trace("doing my staff...");
    		}
    		
    		final override public function reset():void 
    		{
    			doMyStuff();
    			super.reset();
    		}
    		
    		final public function $reset():void 
    		{
    			super.reset();
    		}
    	}
    	
    }
    Code:
    package  
    {
    	
    	/**
    	* MyTimerExtends class.
    	* @author wvxvw
    	*/
    	public class MyTimerExtends extends MyTymer
    	{
    		
    		public function MyTimerExtends(delay:uint, count:uint = 0) 
    		{
    			super(delay, count);
    		}
    		
    		/**
    		 * Error: Cannot redefine a final method.
    		 */
    		override public function reset():void 
    		{
    			super.reset();
    		}
    	}
    	
    }
    Last edited by wvxvw; September 20th, 2008 at 09:53 AM.

    I support FlashDevelop (the .NET open source editor for Flash and web developers)
    couchsurfing if you need it

  3. #3
    Do you want to make it an abstract class? Like DisplayObject? Where you can't actually make DisplayObject instances, you can only have it as a superclass of other classes?

    If so, ActionScript does not directly support abstract classes. And though DisplayObject is, its enforced through C code. You can try to enforce it yourself with an error, though.

    Code:
    public function MyTymer(delay:uint, count:uint = 0) 
    {
           super(delay, count);
           if (Object(this).constructor == MyTymer) throw new Error("You must create subclasses of MyTymer");
    }
    So if anyone tries to make an instance of MyTymer directly, an error will be thrown.

  4. #4
    1,596
    posts
    Holosuite User
    You cannot throw errors before calling super(), you'll get an error... a compile-time error, I mean...

    I support FlashDevelop (the .NET open source editor for Flash and web developers)
    couchsurfing if you need it

  5. #5
    Quote Originally Posted by wvxvw View Post
    You cannot throw errors before calling super(), you'll get an error... a compile-time error, I mean...
    fixed

  6. #6
    Yeah... I'm not trying to make MyTimer methods final, but protected. The point is that 'reset' method is defined by the super class (Timer) as public. I would like to convert it to protected, making a kind of abstract class.

    Great tip senocular, I'll implement that error.
    Last edited by ad.sign; September 20th, 2008 at 02:44 PM.

  7. #7
    And about faking the Abstract Class behavior... just one last question. Is there a name pattern to indicate that one Class is 'abstract'? Or usually we should use a default ClassName?

  8. #8
    Not really. You can use Abstract<ClassName> to be obvious, but other than that there's nothing.

  9. #9
    In your example senocular, I suppose someone could still extend the MyTimer class and simply not call the super() constructor. Though at that point they're on their own if things start breaking.


    In the base class you could also throw exceptions in the methods:
    PHP Code:
    public function reset():void 
    {
        throw new 
    Error("You must implement/override this method!");

    It wouldn't provide compile-time checking, but at least at run-time it would report it.
    Last edited by FizixMan; September 20th, 2008 at 02:10 PM.

  10. #10
    1,596
    posts
    Holosuite User
    Even if you don't call super() explicitly, it's being called in the first line of the constructor. So, this is not the case... And, in this specific case you must call super, because the first argument of the superclass is mandatory.

    Considering Timer, I see no point in changing built-in superclass behavior by hiding some of it's methods. It'd be more "user-friendly" to just create your own class with the timer inside and expose inner timer's methods through your custom class methods... The only reason of not doing so would be if there ware any built-in classes which required arguments of type Timer (in which case, you'd need to make your class compatible with those methods).
    But, honestly, I'm not sure what was your final goal...

    I support FlashDevelop (the .NET open source editor for Flash and web developers)
    couchsurfing if you need it

  11. #11
    Yeah wvxvw.. I agree that doing this could not be the best way... but sometimes it sounds like a more organizated approach to keep EveryTimer or EveryClass with Timer behavior inheriting from this unique source (Adobe Timer Class).

    Tanks everyone for helping with all those questions!

  12. #12
    Ahh, makes sense I suppose.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Home About kirupa.com Meet the Moderators Advertise

 Link to Us

 Credits

Copyright 1999 - 2012