Firstly I wanted to say that I dont want this topic to seem like an adobe bashing thread, it wasnt my intention or the sentiment behind this but I know how these threads can go back and forwards and each step everyone digs in a bit deeper especially when one percieves the other as ridiculing them...
So this was only meant to be a friendly chat and my views are only due to the fact that I really WANT to use the framework rather than role my own to create components, if I didnt I wouldnt care. I actually like the suggestion about using a different namespace, actually instead of mx_internal, how about mx_development.. a special namespace soley covering private vs protected and to be used by component devs at their own risk.. I would have no problem with that, in fact would love that if the alternative is never getting access to something. Actually I was inaccurate when I said 1000 of each for functions it is 1k+ private, 275 protected (the other 750 are overrides in subclasses). The problem with giving specifics is that to be honest if I make a report and go into lengthy text of why I need to do something, and it is only going to make sense if you understand the full context and if I am really, really lucky and it actually gets read by someone who thinks it should be changed it will take a year or more at least for it to be released maybe even 2 years. >From a business perspective as a component dev that is just the same as never, I cant sit and wait, so I work around it, if I have worked around it and moved on I probably wont come back to rework it back to the orginal concept when 2 years from now you release it. So reporting specifics has no practical benefit for me and just wastes my time (take that as "from a practical point of view" not literally, please). There are always ways round the problem and I will have figured that out, but the ways round will almost always be less effecient and performance has been and still is a very big issue for flash components/applications, I am generally not looking to get advice on the way round I am looking for someone to give me access right though the middle and as I said if this is going to need to be API by API with developers trying to convince some anon person it will take forever. Its not that I am not at all willing but it feels like it will be an absolute mountain of work for me with no effective payback. tks --- In [email protected], "Gordon Smith" <[EMAIL PROTECTED]> wrote: > > > dare I suggest it seems they only are protected when adobe needed to > do so > > in order to create there own subclassed components. > > Sure you can suggest it, and it's basically true... the only components > that most of us developers on the Flex team have developed are the ones > in the framework! It's outside developers like you that do the > extending, and you run into problems that we didn't consider. That's why > we're asking for specifics about the problems you're encountering so > that we can make you happy while keeping the framework flexible. > > - Gordon > > ________________________________ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of reflexactions > Sent: Thursday, June 14, 2007 8:27 PM > To: [email protected] > Subject: [flexcomponents] Re: Private vs Protected > > > > Personally the idea of people using the open source framework to role > there own version of it troubles me. > > With framework caching now a reality, the last thing I as a component > developer want is to release components based on a frame work only to > find at run time that the framework isnt the one I designed the > component against or some such related issue. > > I also dont want to role my own version of the framework and then be > in the business of supporting it for all the people who use my > component, thats adobes job. > > I dont mind creating different versions of my component to work with > different official versions of the framework but I do mind if it > becomes a complete free for all. > > FYI As a "measure" of the size of the problem, there are 2000 private > vars in the framework and only 128 protected var. Functions are more > balanced with a 1000 of each (though mostly they are overrides), dare > I suggest it seems they only are protected when adobe needed to do so > in order to create there own subclassed components. > > --- In [email protected] > <mailto:flexcomponents%40yahoogroups.com> , Bjorn Schultheiss > <bjorn.schultheiss@> wrote: > > > > Fair enough, > > > > The argument of change has been put forward and i guess that > strikes > > a cord in most developers. > > And Flex 3 is open-sourced and we can do whatever to the SDK, > beautiful. > > > > IMO, the point is quite clear. > > Private members kill the idea of a truly extensible framework and > > makes component development a pain. > > > > > > my two cents > > > > Bjorn > > > > On 15/06/2007, at 12:20 PM, Josh Tynjala wrote: > > > > > Agreed. > > > > > > As a component developer, I understand how many of you guys are > > > frustrated that it can be difficult to extend the existing Flex > > > components. I've been there myself, and it can be time consuming > to > > > find the right workaround. However, I fully support Gordon's > > > reasoning for the private variables and things. > > > > > > I have a feeling that most custom components built for Flex > 2.0.1 > > > will be able to easily transition to Flex 3 with only minor > > > changes. If all the variables and functions went from private to > > > protected or mx_internal, you'll find yourself facing many more > > > changes from one version to the next. In fact, it could be much > > > worse because such an open architecture might mean that you'll > have > > > to fully recreate your component from scratch. Right now, I know > > > that items that are public or protected probably won't change > much > > > if at all, and I like that safety. > > > > > > My two cents. > > > > > > -Josh > > > > > > Gordon Smith 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 OfBjorn > 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 > > >> > > >> > > > > > > > > > > > > > Regards, > > > > Bjorn Schultheiss > > Senior Developer > > > > Personalised Communication Power > > > > Level 2, 31 Coventry St. > > South Melbourne 3205, > > VIC Australia > > > > T: +61 3 9674 7400 > > F: +61 3 9645 9160 > > W: http://www.qdc.net.au <http://www.qdc.net.au> > > > > ((------------This transmission is confidential and intended > solely > > for the person or organization to whom it is addressed. It may > > contain privileged and confidential information. If you are not > the > > intended recipient, you should not copy, distribute or take any > > action in reliance on it. If you believe you received this > > transmission in error, please notify the sender.---------------)) > > >
