With (super)

[tadster]

Is this kind of structure ok?

package
{

 import flash.text.*;

 public class NeedsExtension extends MustExtendMe
 {

   public function NeedsExtension() 
   {  

      doThis(); //protected methods of the extended class

      doThat();

      var txf:TextField = new TextField();

      txf.text = someVariable; //somevariable is a protected variable from the extended class

      addChild(txf);


      //so, this class needs to extend a class with those protected mehtods/variables
  
   }
     

   public function whatWeHave():void
   {

       someVariable += "Variable";

   }


 }
}

package
{


import flash.display.Sprite

public class MustExtendMe extends Sprite
{

  protected var someVariable:String = "Our";

  protected function doThis():void
  {

   someVariable += " ";

  }

  protected function doThat():void
  {

    with (super) {

      whatWeHave();
      //so, anything public from NeedsExtension could go here
      //and this class must be extended by a Class that publicly defines whatWeHave

      //...and this is my question, is this part ok? The whole with(super) situation?

      //you see, this way its kind of like an interface with variables...

    }

  }

 }
}

via with(super) it's kind of like an interface with variables...

[ASWC]

It's not really kinda like an interface since it's not enforcing anything. Any subclass could still never implement the method whatWeHave() and if they do what would not make them a special type. So you could still have subclasses implementing it and other not implementing it and (theoretically) no way to know which does what.

[lordofduct]

that with(super) doesn't make sense because super is the upper class (in this case Sprite), not the sub class (in this case NeedsExtension)

super classes shouldn't need to know anything about its sub classes. So methods that aren't defined yet, but are only defined further down the class hierarchy should not (and can not) be referenced... as there is no guarantee that said function even exists.

Now of course MustExtendMe can define a function called whatWeHave, and that function doesn't do anything, and then any sub-class can override it. In which case it's like an abstract definition (which basically IS an interface in that you are only defining the public access to some method, but no implementation is defined unless overriden in a sub-class).

[tadster]

ok, so i should override whatWeHave, but that does not create dependence
if all i'm doing is overriding, whatWeHave does not have to be defined.

And ASWC is right also, but the idea is really just for the two classes,
they are "married" to one another.
The basic idea is variable specific methods (and the variables themselves) in one class, and the use of those variables in another.

This whole with(super) thing actually works!
(even on a big scale, that's what led me to this question)
I stumbled upon it today as a quick way
to separate out code

NeedsExtension becomes the upper class, no? ...No!
So the real quedtion is why does it work!?

For some reason with(super) does not reference Sprite,
it does reference NeedsExtension it's like saying super.whatWeHave(); ...

ok, this is what is going on, i just saw it after starting to write this..
It is doThat that calls for the super
so the "super" is doThats (the functions) super - NeedsExtension

This is true even if the protected function is called from outside the constructor.
The two classes are one, the one does not work without the other.
And Sprite comes along for the ride.


If you wanted you could get crazy with it and define everything that the "first extender" will need:

pacakge
{
public class MustExtendMe extends Sprite{...//protected stuffs}
...

public class eventDefenition extends Event{...}
public class arrayDefenition extends Array{...}
...
}

then for types NeedsExtension would just use those instead.

If you wanted you could go as far as no imports in NeedsExtension, so then a more appropriate name for MustExtendMe would be NeedsExtensionsVariables.

[ASWC]

It's interesting but I would not recommend to go that way anyway since it all depends on the scope of super (it seems). So then if you subclass a subclass what do you get? An error? Or does that mean you need to override but then how do you enforce an override? If you run into these problems then only way to enforce anything is to make the subclasses final but the whole process seems rather dirty and error prone imo.

[tadster]

So then if you subclass a subclass what do you get? An error?

No, NeedsExtension can still be a subclass, but this desgin would be the end of an app
with NeedsExtension being the main model.
Because MustExtendMes vars are protected they all get inherited by NeedsExtension
so any class that extends NeedsExtension would be able to call its methods just like normal. And i guess could overide it's methods... but NeedsExtension would be the main class of an application that would only get extended to perhaps be put on the stage or to control how/where/when it gets constructed.

Erros happen if the methods that MustExtendMe uses in the with(super) are not defined in NeedsExtension (or itself), or if the variables used by NeedsExtension are not declared in MustExtendMe (or itself); thus creating a runtime dependency.

notice that MustExtendMe has no constructor.
i did not write it out the way i'm really using it,
and ok its not really like an interface since if you don't use a var nothing happens but

protected var...
protected var...
protected var...

it's very easy to look and see what variables NeedsExtension can use. And this way keeps that clutter out of the main class.

Any class would be able to extend MustExtendMe so long as it defines whatWeHave,
and could pick and chooe what specific vars it wants to use, and add others if need be.

Ignore the whatWeHave method and the super situation and you can see what i mean, one class holds the variables and another uses them.
Using super provides a way for not only the private vars to be shared between the two classes but also public functions.

The big picture: everything private in one class,
everything public in another.. in the end all public functions of my app will be callable from javascript, so i want a way to see them clearly and separate them out...
perhaps there's a better way to do that?

[ASWC]

Sure, an Interface and all class implementing it will implement the same methods and produce different results (which I guess is what you are getting at). With that your code now can check the type of the instance and call the methods accordingly.

[tadster]

yes, yes I understand that, but this way they implement the same properties not just methods, and i don't need a third file.
Edit: The two classes together produce one unified result.

[ASWC]

You are not a big Interface user are you?

[tadster]

You are not a big Interface user are you?

yes exactly...
Perhaps I don't have the best understanding of interfaces but to my knowledge, it's just a declaration of methods, and then whatever implements the interface has to also define the methods, in full. ?
So, in the interface you have to type out the methods and what they return and so forth, and in the implementing Class the same thing, but with functionality inside. yes?

You can do getters and setters in an interface but not properties, and, in
the implementing Class all the methods must be publicly defined.

imo all this seems unnecessary depending on what your doing, I like having functions that are universal, not changing... so in theory with the protected variables method you could have one class that defines all functions/properties you could ever need in an app, and then just extend it for whatever app your making...

Furthermore, in said app no redeclaration of the functions would be needed, you would just use them... including variables, which is the big power.. you could define a whole set of variables ready to just be used, types and all.

beyond one big holder of universal functions and variables, if part of my app deals with just the loading of things it can simply extend a Class called perhaps, LoaderSet

package
{
import flash.display.Loader;
imports...
public class LoaderSet extends Sprite
{

protected var loader:loaderDefinition;
protected vars...
protected function basicJustLoad(theLoader:loaderDefinition, loadThis:String):void
{
   var loaderHadAChild:Boolean = false;
   if (theLoader && theLoader.numChildren > 0) { theLoader.unload();loaderHadAChild = true; }
   if (theLoader && loaderHadAChild == false) 
  { theLoader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, 
   function (e:Event):void {}, false, 0, true); }
   try {theLoader.load(new URLRequest(loadThis));} catch (error:Error) {}               
}   

}
public class loaderDefinition extends Loader{....}
...

(loaderDefinition comes along as well, so LoaderSet is better thought of as a package, it is LoaderSet.as)


If my particular class deals with loading things via a loader it can just extend LoaderSet
and use its functions:

public class loaderControler extends LoaderSet
{

public function loaderControler(...args)
{

//...


}

public function doALoad(input:String):void
{
   if (!loader) loader = new loaderDefinition(); //loader has already been established
   //in fact this class has no imports at all
   //everything needed for its opperation is in LoaderSet
   basicJustLoad(loader, input);
   addChild(loader); //Sprite came along
   //LoaderSet can be passed around and just used with no redeclarations needed.
   //even the variables
   //and
   //they remain private
}

}

Then,

package
{

public class the AppHolder extends loaderControler
{
  public function AppHolder() {
    super(//settings for loaderControler);
   //with loaderControler being the real app, this class just giving settings
   //an easy way for some other developer to change the settings
  }
}
}

is one way to do it, or

package
{
import flash.display.Sprite;

public class AppHolder extends Sprite
{
...
//loaderControler is in the same folder

addChild(new loaderControler(settings));
...
//and if we had similar sets of classes, they can be added as well
//to form a robust application with its underlining classes being easily reusable
addChild(new graphicsControler(specs));
...
//with each class also initializing when instantiated, their processes
//forming the heart of the application.
//this class serving as an easy way to alter stage settings, or the positions
//of the classes (or their results) on the stage, or the settings of the app classes. 
}

}