haXe Forum > problem with overriding properties

• Martin Dudek Oct 19 at 07:08

  Good morning,

  hope all are well.

  Here comes another newbie question from a confused guy trying to convert the flare visualization toolkit from AS3 to haxe. Flare is using a DirtySprite subclass of the Sprite class to indicate when a rendering relevant property of a Sprite has changed. For that it overrides the public fields x,y etc of the DisplayObject class. While this works peerless in AS3 I have no clue how to do it in haxe. To exemplify the problem I put an example subclass together .
  

  class MyDisplayObject extends DisplayObject {
      
      public var xReadCounter:UInt;
      public var xWriteCounter:UInt;
      
      //error: Field x has different property access than in superclass
      public  override var x(getX,setX):Float; 
      
      public  function getX():Float {
          xReadCounter++;
          return super.x; //error: Field super cannot be accessed for reading
          
      }
      
      public  function setX(v:Float):Float {
          xWriteCounter++;
          x = v;
          return super.x; //error: Field super cannot be accessed for reading
      }
      
      public function new() {
          super();
          xReadCounter = 0;
          xWriteCounter = 0;
      
      }
  }

  As already included in the comments in the class I have two problems.

  * how to access the x field in the super class (super.x obviously doesn't work)
  * how to override a field of the super class in a "property" manner.

  Any hints highly appreciated.

  Greets

  martin
  

• Martin Dudek Oct 20 at 12:51

  Good morning,

  unfortunately I just found the following "negative" answer from Nicolas

  http://haxe.markmail.org/message/fudib6lvvzjwomf4?q=property+override#query:property%20override+page:1+mid:fudib6lvvzjwomf4+state:results

  Hmm, still hope this has changed since then, feels like the first case where haxe is big time less elegant than AS3, introducing an additional property seems confusing and error prone.

  Wonder how others deal with similar cases, seems like a quite common task I try to implement

  Greets

  martin

• Franco Ponticelli Oct 29 at 20:48

  The common approach is to favor composition over inheritance. That means that the code you are trying to port should be refactored to not extend native object but to wrap them. This is not obviously a solution to your problem but a different approach that in many cases is also better.

• Martin Dudek Oct 30 at 19:44

  Hi Franco,

  thanks a lot for the feedback, highly appreciated.

  As you already hinted composition doesn't do in my concrete case since I need to use a subclass of DisplayObject in order to be able to add the resultant class as child to a stage. And a "addYourSelfToTheGivenStage" kind of method as composition would demand it is not really appealing.

  Still hope to get any other suggestions. I really would love to contribute a haxe port of the flare toolkit to the haxe community, yet I obviously have to get around the described problem.
  Independent of this concrete problem I would really love to learn why haxe is so restrictive in this regard, my initial and still vivid enthusiasm about haxe gets unfortunately a bit reduced right now ...

  Greets

  martin

• Ali Jaya Meilio Oct 31 at 09:29

  hmmm... i think we can write it like this

  class SpriteCom
  {
      public var sprite:Sprite;
      
      public function new()
      {
          sprite = new Sprite();
      }
  
      public function addChild(child:DisplayObject) : DisplayObject
      {
          sprite.addChild(child);
          return child;
      }
      
      public function addChild2(child:SpriteCom) : SpriteCom
      {
          sprite.removeChild(child.sprite);
          return child;
      }
      
      // and soon
  }

  And add to stage can be accomplished like this
  Lib.current.addChild(spriteCom.sprite);

  it's not a problem to set 'sprite' property to public and some changed syntax :D

• Martin Dudek Oct 31 at 10:22

  Hi Ali Jaya Meilio,

  thanks a lot for the suggestion. What I struggle with is

  Lib.current.addChild(spriteCom.sprite);

  yet making the sprite object public as you suggested is pragmatically seen definitely nicer than what I thought of by having a method adding the private sprite internally.

  The main reason why I am hesitating at this point is that I want to make the haxe port as close as possible to the AS3 original of course and the flare Sprite subclasses (NodeSprite etc) are a very central feature of flare (the nodes and edges in the graphs for example). So if things get even a bit more complicated in the haxe port it wouldn't particular advertise haxe (and the flare haxe port) I am afraid and an explanation for it like you can't override properties of Flash9 classes wouldn't help either I assume. Nevertheless maybe just too much of concern ...

  Still hoping for further discussions on this

  Thanks once more and greets

  martin

• Franco Ponticelli Oct 31 at 17:11

  The reason why you can't override properties is because other platforms do not support them at all. haXe has its own implementation to make it work the same on every platform but it is not fully compatible with native objects.

• Franco Ponticelli Oct 31 at 17:11

  Refactoring to composition has the side effect that make it easier to port your library to other platforms too replacing just the visual part and not the whole class inheritance.

• Martin Dudek Nov 01 at 08:51

  Hi Franco,

  thanks a lot for the further clarifications.
  Obviously my questions,confusion about haxe is coming mainly from me not thinking about haxe as a multi-platform targeting language.
  Another thought which popped up after reading your reply, wouldn't it be possible that haxe defines the field of the Flash9 classes in a "property manner"
  

  extern class flash.display.DisplayObject
  //...
  //var x : Float
  var x(getX,setX) : Float;
  //etc ...

  This would obviously solve my concrete problem. While this is not particular important I heard some hints that other AS3 -> haxe port projects broke down around the very same problem. Apart from that writing a complete AS3 to haxe converter seems to be impossible as long as this limitation exists.
  Sorry for being so pushy, the reason while I keep investigating is that I am really drawn to the haxe community and would be happy to leave the AS3 world behind.

  Anyway, just some further thoughts on this

  Greets

  martin

• Justin L Mills Nov 01 at 10:27

  Logic structures and visual structures are not the same and I do not believe a view must extend a display object but rather contain some, the original style of flash was to have complex MovieClip structures, but then communication and logic becomes difficult and expense is absorbed on bubbling events, and sometimes granulates your code to abstract levels that may suit java but not rapid visual creative logic. I agree that haXe has some issues with inheritance that are maybe unacceptable to AS3 developers but I also think there is too much dependence on inheritance, for instance early versions of papervision ( eg: as2 version ) had complex inheritance chains... but they reduced significantly as speed and flexibility were factored in, I am not sure if that was conscience decision or just trial and error. Often an issue of composition that it takes more code than inheritance if you compare class to class, but if you make full use of 'typedef', 'using' etc... and structure differently then I doubt this is the case as you can also use less classes.
  .
  My thought on your suggestion, and its only a guess, is that haXe is like swish, it wraps flash classes to allow mixing with its code, now you can't just change the DisplayObject container since it is inherited by other inbuilt flash classes, and how would you get flash code running in a haXe swf to work, since a haXe DisplayObject would be a different class from a flash DisplayObject and remember these classes are defined outside the ApplicationDomain so its like old school hacking MovieClip prototypes, you load a new Movie in and suddenly all the MovieClips have a bounce method or you load a haXe movie into a flash one and...
  So I think there are huge limitations to what haXe can do to the inbuilt classes.
  From a practical point of view maybe if you port the code and it forces some style changes they could be back ported and improve the AS3 code, as inheritance is over used in AS3.
  .
  But I am probably totally wrong in my thoughts and approach and would be the first to admit to being creative rather than hardcore coder.

• Martin Dudek Nov 01 at 23:39

  Hi Justin,

  thanks for your thoughts, very helpful.

  Just briefly yet maybe good to mention that flare is maybe not a typical AS3 project, the people behind the project, foremost Jeff Heer, are coming from a strong computer science background and are basically brilliant software architects. Composition over inheritance as a general advice is surely well known by the flare team, the concrete classes around which my attempt of a flare haxe port struggled are at least from my understanding surely a case for inheritance.

  As it seems I will give up the idea of flare haxe port and think about a haxe visualization toolkit inspired by flare. Since I was planning to refactor the flare haxe port in a second step a bit in order to fit it into the puremvc framework maybe I should go straight there. (or I assume robotlegs is more hip now, just have to wait for a haxe port ... anybody working on it or thinking about it?)

  So for now thanks to the community for the discussion here which definitely was an eye opener for me and very helpful to understand haxe a bit better. More thoughts on this topic are of course still most welcome.

  Greets and thanks once more

  martin

• Reply