Comments on: These annoying protected variables in Flex framework

By: judah

judah — Fri, 16 Nov 2007 00:36:01 +0000

I wrote a similar post about private variables (http://www.judahfrangipane.com/blog/?p=77). Chuck made a good point that if some variables were made protected or public the result could lead to buggy behavior.

I asked some of the Flex engineers why and they said that unless it was deemed necessary, they would use private variables instead of public because of optimizations made by the compiler on private variables. I’m not sure if those same optimizations are available to protected variables but I don’t use protected variables. The reason I sometimes use private variables is because I don’t want an application developer or user of my components to see every single property on my class. It would be way too much and too many “similarly” named variables where the only one I want them to use is the one I mark public. But I really think protected variables have been misapplied. I think they should be in the same class as mx internal. If they were still accessable but with an implied warning that may they not be safe to use and not show up in MXML code hinting then I think we might solve the reasons behind why protected variables were created. IMHO

By: dejager

dejager — Fri, 26 Oct 2007 16:20:43 +0000

The original question I addressed was, ‘why do we need protected variables?’ Not ‘why Framework Developer put the protected modifier in the first place?’ If you wanted a definitive answer to your second question I’m sure you can get one from any number of the engineers working on the Flex framework. From my experience I’ve found them to be quite transparent.

By: Yakov Fain

Yakov Fain — Fri, 26 Oct 2007 15:51:37 +0000

You can\’t override a function increasing its accessibility.
But neither you nor dejager are answering my question: why Framework Developer put the protected modifier in the first place? Because he was under impression that the only way to use it is by forcing Component developer create a subclass? Why does this Framework developer forces me to use inheritance and not composition?

What you call a \”friendly hint\” can be better called \”Framework Developer is not sure how this particular property is used by other components of the framework, so he decided to declare it protected just in case\”.

Your arguments are not convincing.

By: vsilaev

vsilaev — Fri, 26 Oct 2007 14:38:38 +0000

Yakov,

Very strange way to override a property to make it public. Should be something like this:

package {
import mx.containers.VBox;
public class VBoxScalable extends VBox {

override public function get unscaledWidth():Number { return super.unscaledWidth; }
override public function get unscaledHeight():Number { return super.unscaledHeight; }

}
}

Anyway, let me disagree with you regarding protected variables. There are 3 roles involved here:
– Framework Developer (developer who puts “protected” visibility modifier)
– Custom library / component developer (who may use framework class as base and use all protected properties and even expose them to public)
– Application developer (who assembles application from components provided by [1] and [2])

In fact, you have to play both roles [2] and [3] during development, but I can’t say this is limitation. So when your cursor is placed somewhere between mx:Application tags you definitely may find certain design decisions of [1] boring, but if you quickly change your role from [3] to [2] you can easily fix this

“Private” is real limitation — just use some functionality “as is”, or reproduce it completely. “Protected” is just a friendly hint — this code may have side effects that are better controlled inside component code rather then from outside.

Anyway, [2] may always decide: ok, there is nothing wrong for these properties/methods to be public, at least for known set of applications (typically developed within same company). [1] has no such freedom for similar decisions.

By: dejager

dejager — Thu, 25 Oct 2007 22:56:06 +0000

The short answer is, we need protected variables and we don’t need protected variables. If anything, the protected keyword communicates a designer’s original intention for a property. Whether you use it or not in your own code should be a decision that is left entirely up to you. This being said we should be respectful of the fact that other designers may have logical reasons for wanting to limit the accessibility of a property, even if these reasons aren’t apparent to us at first glance. Some people choose to lock their front door and only give themselves and their children access to the things found in their house, while others live without doors have no qualms about exposing all of their possessions to the world. Both examples are based on personal preference, neither of which is right or wrong. However, while the person without doors may not mind you wandering through their house using their possessions, a person who chooses to live with their doors locked may require of you certain requirements (some type of relationship, a request to use one of their possessions, etc), even if you personally would never ask those things of someone else. These requirements, though not stopping you (you could always crawl through an open window, getting around a locked door), do set up guidelines for how the designer (owner) of the properties (possessions) expects others to interact with her/his objects. We should respect these guidelines and try to work within them whenever possible, even if the requirements for doing so seem a bit wacky from our point of view.

By: tearaway_Tea

tearaway_Tea — Thu, 25 Oct 2007 21:53:12 +0000

Yeah, I totaly agree with you. There is no sens of using protected properties and fields only methods.