With the display list in Actionscript 3.0, I'm often inclined to have children add themselves to their parent because they often already have that reference. That would look like:
_myParent.addChild(this);
or when removing...
this.parent.removeChild(this);
By the wording of the addChild() syntax, this way seems backwards -- the name suggests the parent should be the only one calling that function.
Does anyone else do this?
Or does this seem backwards and confusing?
Perhaps I'm getting myself into situations I shouldn't be in?
It seems like a violation of responsibilities because the parent should be the only one calling its own method and in charge of its own display list.
You'll want to be cautious whenever a child refers to its parent. While it doesn't break any rules associated with Object-Orientation, it does start to make your Composite structure more difficult to maintain and understand.
The Display List in ActionScript 3.0 is designed to use method calls when interacting with children, and events (sometimes bubbling) whenever a child does something that may be interesting to a parent.
This direction helps us keep children ignorant of their position in the hierarchy, and design them more like general purpose (reusable) components. In general, an ActionScript Display List moves from more to less specific as it moves from parent to child. For example, a CreditCardForm might contain a TextInput control.
Though it is not a good practice, this.parent.removeChild(this); is sometimes convenient (depending on your design) - and I remember doing it in the early days of AS coding... then i was advised that its not a good way of doing it and i dnt use it anymore.
Regarding _myParent.addChild(this); -- I don't usually pass the parent object to the constructor/methods of child... I think this practice has its roots in AS2. And yeah, it looks strange/confusing since its not the AS3 way.
It seems bad to me as the state of the parent is its children. So by having reference to child you can change parents state and it breaks the encapsulation.
Let`s think of a simple case when you need to implement drag and drop. It can be done in this way:
Tell child to remove his him from his parent. Then tell child to add him to a new parent. And parents are not even know about that :-).
Tell parent - I need your child. He will remove that child. Then tell to other parent: from now on this child is yours.
The second way seems more reasonable to me, because if you need to reject some children (parent cant have some types of children, or need to do some actions when you are getting new children, like prepare a bedroom, or buy some toys), youll be have to call all this from your child class. And this will require show all your parents implementation for that.
Sure it can be done via generic interface of parent, but I think its much easier to delegate this responsibility to parent and provide child. Every parent will know what he should do to add this child.
_myParent.addChild(this);
Let's break this down...
_myParent
This is a reference to another object, which happens to be the object's parent on the display list. There are many reasons for an object to have a reference to its parent. They are closely related in structure, so likely have reasons to communicate with each other. So, having a reference to the display list parent isn't an issue.
addChild()
Calling one of the parent's public methods isn't an issue. That's what methods are for. If this were a property of the parent, it would be invasive. Calling this method won't directly alter the parent's state. The parent will carry out this function at its own discretion.
this
The fact that the argument in this case happens to be self-referential is a coincidence. If the argument were something trivial such as new Shape(), it would seem less awkward. But, since an object is essentially "adding itself", it seems something like a person lifting himself up by his/her bootstraps. But, this isn't real life; it's computer programming, and it makes sense when read by its syntax.
Actionscript needed to name the function something. The other alternative for getting a child onto the display list could have been addToParent(), which would still have the same awkward effect when trying to add a child from the parent -- _myChild.addToParent(this).
So, while there are no objects being violated in this awkward predicament, there is a more natural way of writing addChild() statements, and that's to add children from parents, instead of the other way around because that's the order laid down by the syntax. So, try to use the natural way, and when that fails, the other way is still okay, just a little awkward.
Related
I have a question:
I have a div which I would like to constantly (at a three second interval) update to a cloud firestore variable which will also be updated. I don't think the firestore aspect of this is important, just the updating div values to a variable. Obviously, the simplest way I could do this is the "getElementById.innerHTML" which works, but becomes a little tedious after a while.
Ive seen the UseEffect stuff, and I think that might be the answer, but before I dive down that rabbit hole, I would like to see if there is something even easier I could do without refactoring all of my code.
One thing I should mention is that I tried to use {variableX} in my html, but it appears it only updates the value of the div on the initial render.
Everywhere I could read about Liskov Substitution, only 1 example is available which is Rectangle and Square and It is explained how we can violate it but no corrective actions are described.
One such example is available at This link :
I want to know corrective steps If we are violating it.
Thanks in advance.
In the case of Rectangle and Square the corrective action is simply, don't implement inheritance between them. The LSP tells us that neither is a parent or child of the other, so keep them separate. They can still be siblings, e.g. both can inherit from Shape; but they are separate branches of the Shape hierarchy.
The other potential solution to an LSP violation between two classes is to redefine one or both of them. This isn't a viable solution for Rectangle and Square because they are defined mathematically; but in a scenario where you have control of the abstraction or its implementation, you can edit the contract to fit the code or vice versa.
Long ago at a conference talk on React I saw the presenter add something to his code that allowed you to click-drag a divider on the screen by getting to within a certain number of pixels of it, rather than have click exactly on it.
It's a handy concept for improving usability, though I don't know what it is called. Adding 'slop' perhaps? Anyway I completely forget how he did it, presumably using some padding approach. Does anyone know what this practice is called and how to implement it? I assume it was something he achieved it with CSS but am not sure.
You can use vanilla js to do that. Using element.getBoundingClientRect() to retrieve the element's offset relative to body and comparing with the actual mouseX and mouseY(in the click moment of course) you now know the distance between the element and the click, now add some logic like: Case distance < acceptable offset then do some side effect.
I got a container with a dynamic number of children sprites. Each child uses a Gestouch PanGesture to allow the user to move it around within the container.
I would like to invoke a Gestouch TransFormGesture on the container so that I can zoom and pan it (pan using two fingers). I have a setup currently with a TransformGesture on the stage. My problem is naturally that if the user wants to zoom or pan, and sets down their first finger onto one of the child objects, that child's PanGesture starts. With my current setup the user would have to aim in between the children to successfully start the TransformGesture
I'd love it if anyone could enlighten me as to what would be a good strategy for solving this? Slop on the PanGesture? Is it wrong to use a PanGesture like I do? Something more elegant?
Dude, I really don't think there are many Gestouch adepts here.
https://github.com/fljot/Gestouch/issues/66
I am porting as3iso to use with my abstract display list but I fail to see the reason why the author decided to use a secondary display list (the node hierarchy). I cannot think of the necessity of this apart from being able to get the children array of a display object. Is it really that big a performance hit to do for(i in 0...numChildren) getChildAt vs getting the children array? This can also be mitigated by maintaining a children array while overriding.
The only other reason is that some properties of flash.display.DisplayObject are final and wanting to have x and y correlate to isoX/isoY, but worldX/worldY is a reasonable API for this.
I have no problem with the secondary display list but I fail to see the point and am leaning toward having my iso display objects extend from my DisplayObject.
Also, I had presumed that marking objects visible=false that are not on the screen or outside of a scrollRect is not necessary with Flash and in rendering in general as this is/should be handled at the renderer level? Is this the case with the flash software renderer?
For the last question, it's useful to set visible=false because that way the renderer can quickly skip this object without having to calculate whether it is within the screen rectangle or not.
This way the library doesn't rely on the rendering system. You can use the traditional flash display list, Stage3D or a custom solution.