RE: [cross-project-issues-dev] Is everyone always visible?

[Harm Sluiman <sluiman@xxxxxxxxxx>]

FWIW, The TPTP project leads got together
and briefly discussed this, and decided to not change anything in this
area as it serves our community well.

Thanks for your time.
________________
Harm Sluiman,
IBM Distinguished Engineer
phone:905-413-4032   fax: 4920  cell: 1-647-300-4758
mailto:sluiman@xxxxxxxxxx
Admin : Queenie Lam qlam@xxxxxxxxxx  Tie: 969-5864 1-905-413-5864

"Mik Kersten" <beatmik@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

09/11/2007 05:29 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To	"'Cross project issues'" <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	RE: [cross-project-issues-dev] Is everyone always visible?

In my opinion part of what makes a good framework
is refined accessibility of to the right data structures and related behavior,
where 'right' is defined by a broad range of clients.  I think that
EMF is a great example of a good framework, and as Ed points out has leaned
towards making things accessible.  On Mylyn we have found that having
internal packages actually makes it easier for us to decide that a type
should be private because we follow Platform's "no mercy" policy
on changing internals. 

I agree that there are important reasons to restrict accessibility and
I find Platform's use of package and private types a great pattern to follow.
 But thankfully Java has evolved with the legacy of Reflection and
Open Implementation in mind, and we have java.lang.reflect, which allows
us to gain access to anything in the type system.  I can think of
numerous examples where we have prototyped something in Mylyn that used
reflective access to a hidden member, filed a bug report against the SDK
to consider making that element visible, and then removed the reflection
in the version of Mylyn built against the latest SDK Milestone.  Without
the ability to prototype the behavior in this way we would have sought
alternatives or re-implemented.  Randy, I think that your recent experimentation
with URLTransfer is a great example of why this kind of accessibility is
useful: https://bugs.eclipse.org/bugs/show_bug.cgi?id=100095#c19  

Both Java's reflection and the Eclipse Platform's visibility conventions
provide mechanisms for specifying access limitations (Java's accessibility,
Eclipse's x-internal), gaining it when needed (Java reflection, SDK's Export-Package
convention) and removing this ability when appropriate (Java's security
manager, Eclipse runtime's strict mode).  Removing the ability to
gain access to a plug-ins internal types is bound to hamper that framework's
quality by limiting extensibility, experimentation and feedback.

Mik

> -----Original Message-----
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-
> project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Randy Hudson
> Sent: Monday, September 10, 2007 11:12 AM
> To: Cross project issues
> Subject: RE: [cross-project-issues-dev] Is everyone always visible?
> 
> Using that argument, we shouldn't have private fields or methods either
> then ;-) ;-) ?!
> 
> -Randy
>
>              "Mik Kersten"
>              <beatmik@xxxxxxx>
>              Sent by:
> To
>              cross-project-iss
        "'Cross project issues'"
>              ues-dev-bounces@e
        <cross-project-issues-
> dev@eclipse.o
>              clipse.org  
             rg>
> 
> cc
> 
>              09/09/2007 08:53
> Subject
>              PM      
                 RE: [cross-project-issues-dev]
> Is
>                    
                   everyone
always visible?
> 
>              Please respond to
>                Cross project
>                   issues
>              <cross-project-is
>              sues-dev@eclipse.
>                    org>
> 
> 
> 
> 
> 
> 
> I very strongly agree with the points that Chris raises.
> 
> As someone who has to evolve and maintain an API, I wholeheartedly
> sympathize with the desire to hide some of the internals that can
make
> a framework fragile or result in a burden when integrators complain
> about changing internals.  But in my opinion the benefits to
> integrators far outweigh the relatively small burden to the project.
> Those building APIs can never predict all the interesting ways that
> their framework will get extended, which is why access to internals
has
> been such a key enabler of extensibility for the Platform.  By
being at
> the bottom of the stack the Platform exposes itself to more of a
> maintenance burden more than any other project, and they have done
an
> amazing job leading by example, and putting safeguards in place when
> needed.  The following blog post has a summary of why I think
it’s so
> important to have access to all of the code in an open
> framework: http://tasktop.com/blog/?p=5
> 
> As a practical matter, for our 3.0 cycle Mylyn is planning to better
> support JEE development via WTP-specific extensions, such as those
> already prototyped in Spring IDE.  The Mylyn Platform/SDK extensions
> could not exist if any of the SDK had inaccessible internals, even
> those that the API developers thought nobody would ever want to access.
> This is because Mylyn is an extension that crosscuts typical API
> boundaries by layering over the tools entire UI and models beneath
that
> UI.  If WTP starts hiding packages this would either preclude
or
> severely limit the Mylyn integration for WTP, and we would get stuck
> doing exactly the “crazy stuff” that Chris is referring to.
> 
> Mik
> 
> 
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Chris Aniszczyk
> Sent: Saturday, September 08, 2007 1:59 PM
> To: Cross project issues
> Subject: Re: [cross-project-issues-dev] Is everyone always visible?
> 
> 
> 
> I don't think this is a good idea personally. WTP isn't a commercial
> product, it's an open source project. The community expects that they
> can access any code, internal or not. If you prevent them from
> accessing certain classes, they'll do crazy stuff like Equinox
> Transforms (
> http://wiki.eclipse.org/Equinox_Transforms) to get the MANIFEST.MF
the
> way they like it.
> 
> My inclination is no to the change especially since this is going
from
> a "everything open come join the party" to "something
things are
> closed"
> model.
> 
> After reading your policy, how will you implement #1? It seems this
> would only be possible for future packages.
> "The only packages that can be made "hidden" are ones
that no adopter
> currently uses and that no one in WTP currently uses, even test
> plugins..."
> 
> 
> 
> In response to what other projects do, I think that's a fantastic
idea
> to document how other projects treat API (although most I believe
will
> follow the traditional Platform model)
> 
> Cheers,
> 
> ---
> Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-
> bloga.blogspot.com | +1.860.839.2465
> 
> (Embedded image moved to file: pic18899.gif)Inactive hide details
for
> David M Williams---09/08/2007 04:26:09 AM---As philosophical as that
> sounds ... I really am asking abDavid M Williams---09/08/2007 04:26:09
> AM---As philosophical as that sounds ... I really am asking about
Java
> code. :) I hope everyone knows
> 
> 
> 
> 
>  From:            David M Williams/Raleigh/IBM@IBMUS
> 
> 
>  To:              Cross project
issues
>                   <cross-project-issues-dev@xxxxxxxxxxx>
> 
> 
>  Date:            09/08/2007 04:26
AM
> 
> 
>  Subject:         [cross-project-issues-dev]
Is everyone always
> visible?
> 
> 
> 
> 
> 
> 
> 
> 
> As philosophical as that sounds ... I really am asking about Java
code.
> :)
> 
> I hope everyone knows that package visibility outside it's bundle
is
> controlled by whether it is listed in the manifest.mf file.
> 
> Historically, we in WTP have followed the Eclipse Platform's policy
of
> always making every package visible to others, even if it was not
API
> and even if it really was never used any where else. But, now we in
WTP
> are considering to change our policy, to allow some packages to be
> hidden, if they really are completely internal. We see this potentially
> as an improved way to specify API's, along with the usual correct
use
> of x-internal, x-friend, etc. And also, we hope it will motivate us
to
> be more careful in our future code and designs to better separate
API
> from implementation.
> 
> So, two things came to mind:
> 
> 1. What do other projects do?, and
> 
> 2. Would it be useful to request each project in Ganymede to document
> their policy?
> 
> To address both these questions, I've started
> Ganymede_Policies_on_Package_Visibility as a place where Projects
can
> specify, and link to, their written policy on the matter.
> 
> So, if you would please, take a minute and fill in the tables listed
> there, if you think it would be useful.
> I created the table assuming each top level project would have one
> policy, and that it would not differ from component to component ...
> so, that's another thing ... let me know if that's an incorrect
> assumption.
> 
> And, by all means, respond here if you have strong feelings about
what
> a project's policy should be.
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev