I understand why things are marked as private versus protected. What I'm suggesting is that enough thought isn't going into it and a LOT of stuff is being marked as private that shouldn't be. This is hobbling component extension. I have dealt with a lot of frameworks and they generally have this problem to an extent. But I have yet to run into it to an extent I have here.
And yes, I have reported this to Adobe on the bug/suggestion page. I will continue to do so on a particular case-by-case basis, but this is a more general problem. The thing that has pushed me to the edge was trying to subclass to make a divided box that can have the divider hidden/shown. It wasn't a matter of one property or function being private. Everything there uses BoxDivider as the class that actually draws the little divider. Luckily, the variable dividerClass in DividedBox was one of the few things marked protected. So you can assign your own class to it. The problem is that everywhere else, it is assumed to be a descendent of BoxDivider. Okay, then, just subclass BoxDivider, right?
Here's what's public:
BoxDivider() (constructor)
set x (because it was public in the base class UIComponent)
set y (ditto)
styleChanged (ditto)
Here's what's protected:
updateDisplayList()
That's it. Everything else is private. Things like vars for what state the divider is in and functions like the mouseOverHandler. I can't even make the mouseover behavior different if I want. And, unfortunately, it registers these private handlers in the constructor. I can't unregister them because I can't pass in the private method name to removeEventListener. And if I don't call super(), I don't get UIComponent's constructor.
Divided box is ALMOST as bad. Luckily, they did make dividerClass protected or I'd be starting from scratch.
This is why I post instead of once again saying "make this variable protected, make that variable protected" As it stands, the whole divided box might as well be considered a sealed class. I think I am going to be able to make some VERY minor changes to it (though I'm still not positive). But if I actually wanted to do anything other than this hack, I'd start from scratch.
I hope people at Adobe don't take this as an attack. I totally understand the position of "if I make it private, no one can gripe when I have to go back and rewrite it." But as it stands, component extensions is going to be severely hobbled. I don't like that, because I really like Flex and want to see it take off.
On 8/10/06, Michael Schmalle <[EMAIL PROTECTED]> wrote:
> mark things as protected by default, not private.I disagree, there is good reason why they marked some thing private. I agree that there are things that should be protected like in the TabNavigator etc.
The implications of marking things default protected go far beyond the desire to get at everything that the lower level has.
You, yeah your probably educated enough to understand the implications of overriding some method that is tied to another method that sets some other property. Most devs don't or do not have the time to see that deep into the framework.
My suggestion, let them know what you are having a problem with and then they can have an idea when they are refactoring.
This is the first as3 version of the framework also, I think it was a great idea that they made more private then protected.
Adobe, what about a dev_internal namespace? instead of making everything protected. You could find a middle ground with a component developer internal namespace like you have going with mx_internal.
To me this would get two things at once. Is there any BAD implication's to that suggestion?
Peace, MikeOn 8/10/06, Paul BH < [EMAIL PROTECTED]> wrote:I second that
On 8/10/06, Pan Troglodytes < [EMAIL PROTECTED]> wrote:Time and again, I have tried extending components only to find that the important stuff is marked private. I suggest this approach for adobe: mark things as protected by default, not private. Only mark something as private if you're really, really sure it should never be overridden by someone extending the class.
This has really thwarted some of my attempts to extend the base classes. Makes the component SDK a bit less useful.
--
Jason
--
What goes up, does come down.
--
Jason
__._,_.___
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
| Web site design development | Computer software development | Software design and development |
| Macromedia flex | Software development best practice |
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
__,_._,___
