Those one-liners are the worst.
On 22/02/2007, at 11:43 AM, Patrick Mineault wrote:
I've had a lot of issues as well with private functions. I would have
suggested to use protected basically everywhere since you can't really
plan for where developers will want to modify the components. As
far as
composition vs. inheritance, well, composition doesn't solve every
problem. I had an issue with the slider class firing data events
when it
received a data-binding value, even though the NumericStepper
didn't do
that. Because the problem function was private and buried very far in
the component hierarchy, I basically gave up. It was a one-liner
kind of
issue too.
Patrick
Doug McCune a écrit :
>
> I've had a similar experience many times, so I'll chime in with what
> I've been doing.
>
> The problem: you want to make a simple extension, and you see the
part
> of the original source that you need changed or enhanced. So you try
> to make a subclass but you end up finding out that to do what you
need
> done you need access to a handful of private variables and functions
> in the parent class.
>
> My solution: I make a cut/paste copy of the original class, name it
> something like OriginalClassBase. as (so like AccordionBase. as) and
> then I extend that new base class. What this allows me to do is make
> some very slight modifications to the original base class, which
> usually only involve changing certain variables or methods to
> "protected" as opposed to "private". This is bad for two reasons: 1)
> you're duplicating the original component in the code base, so
you'll
> bloat the end size of your file and 2) future updates to the
original
> class won't be included in your extended class.
>
> Problem 1 is often worth the price, since that's really the only
way I
> can figure out to do some of the tings I want to do. And I've
already
> resigned myself to multi-hundred kilobyte SWF files, so whatever.
But
> if you're psycho about file size this might prevent you from taking
> this approach.
>
> Problem 2 I don't really see as that big a deal and here's why: the
> changes you're making to the base class are minor. This means
that if
> an update comes out to the Accordion class, my copy/paste version
can
> be compared within Eclipse using the compare functionality and I can
> identify exactly where the differences are. So if an update to the
> Accordion is released in Flex 3, then I can compare my base class
with
> the updated Class, and either make a new base class using the Flex 3
> version, or decide that I don't need to bugfixes and enhancements
they
> rolled into Flex 3.
>
> This is just my approach. What I've found over and over again is
that
> to really make the enhancements I want, the components simply
haven't
> been designed quite right. This isn't to say that Adobe should have
> been able to anticipate every scenario that I would want to do
with a
> subclass. Thank god they included the source for the SDK though.
>
> Doug
>
> On 2/21/07, *Dana Gutride* <[EMAIL PROTECTED] com
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Recently on this list, somebody said that the Flex framework team
> has been surprised at the resistance many developers have to
> subclassing and they'd like to understand it better. I'd like to
> put my 2 cents into this discussion because maybe we can come up
> with some good answers.
>
> I think the ability to extend the existing framework is fabulous,
> but I find that I am hesitant to subclass or extend the existing
> classes. Recently, I spent several days trying to override the
> placeSortArrow function on the datagrid. I ended up ditching my
> code because there were so many private variables used by the
> existing placeSortArrow( ) function that I would need to rewrite
> most of the datagrid.as <http://datagrid.as> file.
>
> I've bought books and searched online for answers, but I haven't
> found anything satisfactory yet. Maybe if there were more
> resources (even if we had to pay for them), we would find more
> developers extending the flex framework.
>
> Dana
>
>
>
>
