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:[EMAIL PROTECTED] On Behalf OfBjorn Schultheiss
Sent: Thursday, June 14, 2007 6:39 PM
To: [email protected]
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
((------------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.---------------))
