New private names proposal

[Mark S. Miller]

On Thu, Dec 23, 2010 at 12:18 AM, Brendan Eich <brendan at mozilla.com> wrote:

> On Dec 22, 2010, at 11:58 PM, Mark S. Miller wrote:
>
> On Wed, Dec 22, 2010 at 11:44 PM, Brendan Eich <brendan at mozilla.com>wrote:
>
>> On Dec 22, 2010, at 11:34 PM, Mark S. Miller wrote:
>>
>> > Brendan, I still do not understand why you think it is illegitimate to
>> consider private names and soft fields as alternatives. Do you really think
>> we should provide syntactic support for both?
>>
>> The discussion here, including Dave's point about transposed get or set
>> for [] being conceptually mismatched to the current [] meaning, and
>> David-Sarah's reply about why you can't stop a third party from using your
>> frozen object identity as the key in a weak map, have convinced me that even
>> the frozen AST example doesn't need syntax, so much as weak maps and
>> whatever soft fields make sense on top of them as library code.
>>
>
> I do not understand this reply. Could you expand?
>
>
> Dave wrote:
>
> "[O]verloading that syntax to mean lookup in a side table is what seems
> like a drastic break from the intuitive model of objects. I have nothing
> against side tables as a programming idiom; it's when you make them look
> like they aren't side tables that they become confusing. Especially when you
> can do counter-intuitive things like add new properties to a frozen object.
> Of course, there are clearly use cases where you want to associate new data
> with a frozen object, and convenience would be helpful. I'm just not
> convinced that making it look like ordinary object lookup is the right
> programmer-interface."
>
> David-Sarah wrote:
>
> "What's your intended goal in preventing 'adding' fields to [a frozen]
> object?
>
> If the goal is security or encapsulation, then freezing the object
> is sufficient. If I add the field in a side table, that does not affect
> your use of the object. I could do the same thing with aWeakMap.set(obj,
> value)."
>
> To answer David-Sarah's question, my goal in preventing "adding" fields to
> a frozen object depends on the syntax used to add those soft fields in
> exactly this way: aWeakMap.set(obj, value) is no problem, but (per Dave's
> words) obj[aSoftField] = value succeeding in spite of obj being frozen *is*
> a problem, conceptually for teachers, learners, documenters, hackers --
> everyone building a mental model of "objects and properties" including
> freezing.
>

Hi Brendan, thanks for this. For the first time I understand why some find
it desirable to not be able to extend a frozen object, even safely with a
side table semantics. I think the issue you raise here can be addressed by
re-explaining "non-extensibility" as suppressing the addition of *public*
properties. I do not know how satisfying you would find this shift, but it
makes sense to me. I would also appreciate reaction from others, thanks.


>
> It seems you agree enough to be exploring @ instead of ., which could
> desugar to transposed .get or .set. So perhaps more new syntax will help,
> rather than less new syntax and too much overloading of old.
>

Rather than more or less, I was suggesting different. I would hate to see @
added to support soft fields in addition to "private" and/or "#" added to
support names. That exceeds my sense of the syntax budget we should be
willing to pay. But if it helps brainstorming not to constrain this budget
early, let's continue to try all syntax proposals on both semantics and see
what the pros, cons, and non-orthogonalities are. We can winnow later if you
like, but please no later than May.



>
> /be
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101223/82ce426e/attachment.html>