Re: [flexcoders] request for adobe: stop being so private

Thu, 10 Aug 2006 13:56:47 -0700

Hey,

I totally agree with you. ;-) Most of what you said I have run into myself. What I have done? I created an extended framework from the Container and use composition(this is mainly for major dnd stuff though).

I know that doesn't solve your problem with say the divided box, you just want to extend it.

Having a lot of experience in writting frameworks that deal with the UI, I would say the problem lies in that this code is still green as spring. I have to go through about 10 refactors before I have fully abstracted methods into tangible and reliable protected methods for subclassing.

My post was more in defense of an infant framework that has not had the time to be refactored on a useful level.

Talk and talk, they are listening and private methods should be calculation and other things that are already finite refactored out of the protected api. Here again we run into the fact that this framework is right off the press just translated from as2 and added to.

I have full faith in meeting the engineers that they are all for creating a subclassable framework that devs can get almost any hook they need without colliding with the essential insides that make this thing tick.

Anyway, I am in your shoes, I ran into this with the tab navigator when doing dnd. I almost rewrote the whole thing and then looked at it a gain and got a bitmore tricky with the way I create my classes being composited INTO their algorithm.

Peace, Mike

On 8/10/06, Pan Troglodytes <[EMAIL PROTECTED]> wrote:

Michael,

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, Mike


On 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




--
What goes up, does come down. __._,_.___

--
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



__,_._,___

Reply via email to