Private names use cases
david-sarah at jacaranda.org
Mon Dec 20 20:46:05 PST 2010
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":
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
> 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...
Size: 292 bytes
Desc: OpenPGP digital signature
More information about the es-discuss