Re: [flexcoders] request for adobe: stop being so private
> Isn't this version 2.0? Or does the component source share almost no code with 1.x versions of Flex?Ah well it's 2 but.. It's 1 in my eyes. This shares the same algorithms in layout. Which is what I am mainly concerned with. As far as I am concerned, it is version 2 Flex, version 1 Flex AS3. Think of this, they had to create all these public interfaces for Flex2 AS3. Just that alone means there is still much refactroing to go. I was with this since alpha, if you were to you then noticed the HUGE API scrub from b2 -> b3 and interfaces disappearing and properties being deleted. Any huge framework is a work in progress in my eyes. I don't know exactly what you are running into but, what makes a great developer is innovation and the ability to be mutable.This world is SO far from perfect how then possibly can a framework be even close to 1/3 of all developers expectations. I think this is the reason you say you run into this with all frameworks. As far as this one being the worse, I can't stress time and patients. > Apparently, FB never calls this. If I remember correctly, direction is stubbed off in subclasses. 2 seconds later...override public function set direction(value:String):voidThey override so you cannot change the direction of an HDBox. Before I ramble, give me some info, I know this thing like well, my guitar maybe I can help. If you subclass DividedBox, the live preview will work correctly changing both directions. Peace, MikeOn 8/10/06, Pan Troglodytes <[EMAIL PROTECTED]> wrote: Isn't this version 2.0? Or does the component source share almost no code with 1.x versions of Flex? I would have expected a 1.x version to be more raw.BTW, I finally gave up on the extension and just cloned the classes. Unfortunately, now my HDividedBoxExt doesn't display properly in FB. Even though I just copied/renamed DividedBox/VDividedBox/HDividedBox and haven't even tried any extension yet. FB shows the HDividedBoxExt with the children layed out vertically, instead of horizontally. At runtime, it works normally. Unfortunately, it descends from Box, which also assumes this. In the constructor of HDividedBox, it does this: mx_internal::layoutObject.direction = BoxDirection.HORIZONTALApparently, FB never calls this. Not sure why it does it with the builtin HDividedBox. But I've run into this before with my other components. So now I get to choose how much I want this feature (a lot). Enough to deal with it being all screwed up in the design mode? Not sure. On 8/10/06, Michael Schmalle <[EMAIL PROTECTED]> wrote: 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, MikeOn 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 dividerCla
RE: [flexcoders] request for adobe: stop being so private
Hi guys, I’m sorry you’ve had frustrations extending the components. Please continue to file requests on the wish form and include the use-case as to what you’re trying to do. We can’t anticipate everything and what you may think is obvious might not have been to us (or our experience designers). As mentioned, making everything protected would immediately bind us into supporting both the APIs and behaviors for a long time, something that we don’t take lightly at this point (no snickering about 1.5 to 2.0). We do have some variables in there that are mx_internal which I think is what Michael is looking for somewhat. This of course is internal for us, you have access to it but there is no guarantee that it will work between versions. Matt From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Jeremy Lu Sent: Thursday, August 10, 2006 9:21 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] request for adobe: stop being so private Flex 2 framework is almost a total revamping, few things were shared from v1.5, guess they still need time to sharpen it a bit. and just like you, for so many times I have to clone the whole class just to modify some of the variables marked private, and ends up with lot of dupe stuff inside, that's really a major pain while deveoping custom components, hopefully this will be solved someday, may be v2.5 dot release ? Jeremy. On 8/11/06, Pan Troglodytes <chimpathetic@gmail.com> wrote: Isn't this version 2.0? Or does the component source share almost no code with 1.x versions of Flex? I would have expected a 1.x version to be more raw. BTW, I finally gave up on the extension and just cloned the classes. Unfortunately, now my HDividedBoxExt doesn't display properly in FB. Even though I just copied/renamed DividedBox/VDividedBox/HDividedBox and haven't even tried any extension yet. FB shows the HDividedBoxExt with the children layed out vertically, instead of horizontally. At runtime, it works normally. Unfortunately, it descends from Box, which also assumes this. In the constructor of HDividedBox, it does this: mx_internal::layoutObject.direction = BoxDirection.HORIZONTAL Apparently, FB never calls this. Not sure why it does it with the builtin HDividedBox. But I've run into this before with my other components. So now I get to choose how much I want this feature (a lot). Enough to deal with it being all screwed up in the design mode? Not sure. On 8/10/06, Michael Schmalle <teoti.graphix@gmail.com> wrote: 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 < chimpathetic@gmail.com> 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
Re: [flexcoders] request for adobe: stop being so private
Flex 2 framework is almost a total revamping, few things were shared from v1.5, guess they still need time to sharpen it a bit. and just like you, for so many times I have to clone the whole class just to modify some of the variables marked private, and ends up with lot of dupe stuff inside, that's really a major pain while deveoping custom components, hopefully this will be solved someday, may be v2.5 dot release ? Jeremy. On 8/11/06, Pan Troglodytes <[EMAIL PROTECTED]> wrote: Isn't this version 2.0? Or does the component source share almost no code with 1.x versions of Flex? I would have expected a 1.x version to be more raw.BTW, I finally gave up on the extension and just cloned the classes. Unfortunately, now my HDividedBoxExt doesn't display properly in FB. Even though I just copied/renamed DividedBox/VDividedBox/HDividedBox and haven't even tried any extension yet. FB shows the HDividedBoxExt with the children layed out vertically, instead of horizontally. At runtime, it works normally. Unfortunately, it descends from Box, which also assumes this. In the constructor of HDividedBox, it does this: mx_internal::layoutObject.direction = BoxDirection.HORIZONTALApparently, FB never calls this. Not sure why it does it with the builtin HDividedBox. But I've run into this before with my other components. So now I get to choose how much I want this feature (a lot). Enough to deal with it being all screwed up in the design mode? Not sure.On 8/10/06, Michael Schmalle <[EMAIL PROTECTED]> wrote: 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, MikeOn 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
Re: [flexcoders] request for adobe: stop being so private
Isn't this version 2.0? Or does the component source share almost no code with 1.x versions of Flex? I would have expected a 1.x version to be more raw.BTW, I finally gave up on the extension and just cloned the classes. Unfortunately, now my HDividedBoxExt doesn't display properly in FB. Even though I just copied/renamed DividedBox/VDividedBox/HDividedBox and haven't even tried any extension yet. FB shows the HDividedBoxExt with the children layed out vertically, instead of horizontally. At runtime, it works normally. Unfortunately, it descends from Box, which also assumes this. In the constructor of HDividedBox, it does this: mx_internal::layoutObject.direction = BoxDirection.HORIZONTALApparently, FB never calls this. Not sure why it does it with the builtin HDividedBox. But I've run into this before with my other components. So now I get to choose how much I want this feature (a lot). Enough to deal with it being all screwed up in the design mode? Not sure.On 8/10/06, Michael Schmalle <[EMAIL PROTECTED]> wrote: 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, MikeOn 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 exten
Re: [flexcoders] request for adobe: stop being so private
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, MikeOn 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
Re: [flexcoders] request for adobe: stop being so private
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, MikeOn 8/10/06, Paul BH < [EMAIL PROTECTED]> wrote: I second thatOn 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
Re: [flexcoders] request for adobe: stop being so private
> 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 thatOn 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. __._,_.___ -- 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. __,_._,___
Re: [flexcoders] request for adobe: stop being so private
I second thatOn 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 __._,_.___ -- 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. __,_._,___
[flexcoders] request for adobe: stop being so private
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 __._,_.___ -- 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. __,_._,___
