FlashApe

FlashApe » Limit the use of ‘private’ in your AS 3 classes

Limit the use of ‘private’ in your AS 3 classes

October 19th, 2007
1:42 pm

In AS2, we really only had two access control modifiers for an object’s properties and methods…public or private (and you can through in static as well, but even static properties could be public or private). In AS 3, we have more options, and ‘private’ works in a different way than in AS 2.

Lately I’ve been digging through a bunch of different AS3 packages that I’ve downloaded, and I’ve run into a ton of situations where properties that should be marked ‘protected’ were marked as ‘private’. Now, the reason this is a problem is that ‘private’ properties cannot be accessed by subclasses. Using ‘protected’ allows subclasses to access the properties of the parent class, without making them public.

I’m not saying never to use ‘private’, but I feel in most situations, ‘protected’ (or even ‘internal’) is what you really want, especially in cases such as component development, or any case where you can almost count on your classes being subclassed.

More info here

flash

11 People had this to say...

FYI, Adobe engineers usually note that using private leads to certain performance gains because the compiler can make optimizations when it knows that a property or method will never be accessed externally.

It also provides them with backwards compatability i.e. they can’t support backwards compatbility of every method and therefore not make it private.

I agree it can be a pain in the a** sometimes.

By marking a property as public or protected, you are declaring that users of your class may modify it safely, without breaking anything. In the case of commercially distributed code there is an implication that all exposed properties and methods have been subject to testing.

Aside from the issue of code-hinting noise in your code editor, there is a huge difference between exposing everything, and designing a well thought out set of extension points.

the difference in execution time for the flash player to execute private vs. protected code is practically nonexistant compared to the dev time it takes for me to go change other people’s source.

tink - backward compatability how? wouldn’t it be the case that once you’re using as3, keeping it backwards compatible with as2 doesn’t really matter? Or is that not what you meant?

This is bad practice you are preaching. Sub-classing is not something to be taken lightly. If you want to sub-class something you should consider composing it instead.

If you want access to internal algorithms for some reason you have to realize the original coder may have only verified those algorithms in certain circumstances which they are aware of and which may not hold in general cases.

The difference between private and protected (or internal) is massive — it must be respected.

peter & james - i understand, and you’re kind of making my point for me…I soetimes get the feeling that thing’s aren’t being thought out, and the use of ‘private’ is just a lingering AS 2 habit. I’m certainly not talking about ‘exposing everything’, what I’m talking about is realizing that many times, you’d want to sublcass over composition (i don’t agree that you should just blindly favor composition over inheritance…you go with what’s appropriate). Take the case of extending a component…I would want to create a subclass of that component rather than create another class which uses that component. In many of the AS 3 components I have dug through so far, the use of private has seemed overkill, when protected would have been more appropriate.

This is especially painful when working with components. You need to work on some piece of functionality, but you’re stopped dead in your tracks when you start seeing that private keyword popping up everywhere.

I understand it makes more work for the component developers to have to test additional external exposure points, but not doing that additional work reduces the extendability of your components. I agree with Rich that lots of Flash and Flex components suffer from this problem.

You should really look into getters and setters…

“tink - backward compatability how? wouldnâ€™t it be the case that once youâ€™re using as3, keeping it backwards compatible with as2 doesnâ€™t really matter? Or is that not what you meant?”

private/mx_internal methods may be changed by Adobe (or who evers code it is) in the future and therefore you can’t guarantee any backwards compatibility with these methods, therefore they are unsafe to override and mark so that you can’t (well u can override mx_internal).

Personally I think making things private by default is the best approach, and only marking them public/protected when u have fully thought out the reason to do so and done thorough testing.

If there is code with the Adobe’s framework you want to override but can’t, you should report it to them and do then same for anyone else code/components your modifying and make them aware of what you are trying to achieve.

WAMP! WAMP! WAMP! Wacka Wacka Wacka Wacka & eat some cheese because we are about to all be poor and hungry animals, rich with experience & too busy to worry about internal protected, private or any other namespaces! WAMP WAMP WAMP!

“rocka” might want to lay off the coke for a little while.

Limit the use of ‘private’ in your AS 3 classes

11 People had this to say...

Want your say?

Contact

Search this site

Gullible

Links

Categories

Archives