Yes, I should have said "public or protected" since both of these introduce the compatibility issues I was referring to, and both have to be documented. - Gordon ________________________________
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Tynjala Sent: Thursday, June 14, 2007 8:25 PM To: [email protected] Subject: Re: [flexcomponents] Re: Private vs Protected In terms of component development, making something public or protected is essentially the same thing. I think it is obvious that Gordon understands the difference between these two access types, and perhaps you've misunderstood his meaning. I will point out that making more private members mx_internal could be an interesting possibility. As it is, mx_internal is considered "use at your own risk", and component developers need to understand that these variables or functions could change without warning. Based on the conversation so far, turning private into anything more accessible would require the same warning. However, I know that Gordon and others from Adobe have faced this conversation and arguments many times before (reflexactions may not have heard it, but I have... several times), so I won't push it. :) -Josh reflexactions wrote: I very clearly didnt say "Make everything public unless you have a great reason for it to be private" I said "Make everything protected unless you have a great reason for it to be private", two VERY different statements (and see this topics title). I havent heard the suggestion before that you only want to expose the "interface" as protected and the rest is private, its a novel way to design a platform framework for sure. tks --- In [email protected] <mailto:flexcomponents%40yahoogroups.com> , "Gordon Smith" <[EMAIL PROTECTED]> wrote: > > Object-oriented languages support private access because hiding > implemention details is essential to producing evolvable code. We try to > figure out what the "interface" of a class should be, and we expose that > and no more. Otherwise the class becomes so brittle that we can't change > it without breaking compatibility... "Somebody might be calling foo () > and it still has to do exactly what it did in 2.0.1 or their code will > break." An alarmingly large percentage of our time is already spent on > that kind of compatibility issue. > > If you can find a book on OO design that says "Make everything public > unless you have a great reason for it to be private", I'd like to know > about it. > > IMHO, we've done a good job of exposing the right APIs for application > developers, but a poor job of exposing the right ones for component > developers. We need to understand much more about how and why developers > are extending our components in order to get the balance right. > > Making the framework brittle and unevolvable is one the quickest ways I > can think of to kill Flex. > > - Gordon > > ________________________________ > > From: [email protected] <mailto:flexcomponents%40yahoogroups.com> > [mailto:[email protected] <mailto:flexcomponents%40yahoogroups.com> ] On Behalf Of Bjorn Schultheiss > Sent: Thursday, June 14, 2007 6:39 PM > To: [email protected] <mailto:flexcomponents%40yahoogroups.com> > Subject: Re: [flexcomponents] Re: Private vs Protected > > > > > On 15/06/2007, at 11:25 AM, reflexactions wrote: > > For a trully extensible framework that is supposed to form the > basis > of this whole platform it shouldnt be left that developers need > to > justify WHY something should be protected, it should be for the > framework author to justify WHY something is private. > > > > > I love it!!! > > That 'play it safe' line was lame. > Use that one for the boss but not for us, the poor devs who might > actually need to reference the private member. > > > regards, > > Bjorn >
