Private names use cases

[David-Sarah Hopwood]

On 2010-12-20 17:21, Allen Wirfs-Brock wrote:
> I've seen mentions in the recent thread that the goal of the "Private Names"
> proposal was to support "private fields" for objects.  While that may be a
> goal of some participants in the discussion, it is not what I would state as the goal.
> 
> I have two specific use cases in mind for "private names":
> 1) Allow JavaScript programmers, who choose to do so, to manage the direct accessibly of object properties.  This may mean limiting access to methods of a particular instance, or to methods of the same "class", or to various friends or cohorts, etc.

Indeed, selective visibility is an important goal of both the private
names and soft fields proposals.

It's important to note that for strong encapsulation, the code
implementing an abstraction must be able to control which other
code can see which fields/properties, but code outside the
abstraction's scope must not be able to decide this for itself.

I.e. +1 for the ability to simulate visibility mechanisms that meet
this criterion, such as Eiffel's export lists, but -1 for the ability
to simulate visibility mechanisms that don't, such as C++'s friend
declarations.

> 2) Allow third-party property extensions to built-in objects or third-party frameworks that are guaranteed to not have naming conflicts  with unrelated extensions to the same objects.
> 
> Of these two use cases, the second may be the more important.
> 
> Note that I emphasized "properties" rather than a new concept such as "private fields".

I think it is a mistake to emphasize that, since it overspecifies the
mechanism. In the soft fields proposal, the fields are not properties,
but that makes little or no visible difference to their use.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101221/3d596738/attachment.bin>