>> * Should hash assignments be by reference or by value? In other words,
what
> > should this do:
> >
> > $h1 = { a => b }
> > $h2 = $h1
> > :
> > $h2[x] = y
> > notice $h1
> >
> > Should the hash in $h2 be a copy of the hash in $h1, or are they the
> same
> > object?
>
> I would say a reference if they are in the same scope. A new copy if
> used in another scope.
>
No matter how I turn that over in my head, I can not make it seem like a
simplification. The argument for copy is that we do not presently have
"hidden" reference semantics (that is, aliasing) anywhere else AFAIK and I'm
not thinking of a good reason to start now.
> * Is array really the right consistency model? For example, one might
> argue
> > that $h should be {content=>bar, mode=>0777} throughout the following:
> >
> > class c0 {
> > file {'/tmp/foo': content => 'bar' }
> > $h = { contents => bar}
> > }
> >
> > class c1 inherits c0 {
> > notice "2: h = $h"
> > File['/tmp/foo'] { mode => 0777 }
> > $h += { mode => 0777 }
> > notice "3: h = $h"
> > }
> >
> > notice "1: h = $h"
> > include c1
> > notice "4: h = $h"
>
> I'm trying to find an use case for this, but I must admit I'm not sure
> to find one.
>
Fragment collection; you could have a class that provides a hash, let others
add elements to it, and you would see all of them from inside the class.
>
> -----------------------------------------------------------------------------------------------------------------------
> > To get concrete, what do you think of the following semantics:
> >
> > * $h1 in the first example above would be distinct from $h2 (assignment
> is a
> > copy).
>
> Hmm, why?
> Or is it to mimic how we deal with arrays?
>
It's how we deal with everything else. The proximate/pragmatic motivation
(apart from internal consistency) is that it limits how broad a net we must
cast to collect all the contributions to a hash.
Jesse:
> related, when you pass a hash as a parameter, is it a copy or a reference?
> assignment should probably work the same way.
>
I think copy is fine there too, but I haven't thought deeply in that corner
yet & would welcome thoughts.
> * The value of a hash is the same at all points in all scopes in which the
> > hash can be seen, and reflects all contributions.
>
> I'm really not sure about this.
>
That's how other hash-like objects (scopes and resources) in the language
work, or will work once we fix the known bugs; it also seems to be the only
way to reconcile h[k] = ... with order invariance; if h[k] = ... is an
assignment rather than a declaration we have different values for h[k]
before and after, which we want to avoid on principle.
> * Hash keys are constrained in some way:
> > * they must be literal strings
> > * or they may not depend on values from a hash
> > * or they may not depend on values in the same hash
>
> That indeed makes sense. Does that also means we can use any rvalue in
> an hash value acces (ie $h[<rvalue>])?
>
Yes.
> My view on all this would be to be quite restrictive on the scope thing
> at first. If we find that it is to restrictive (ie it becomes impossible
> to actually use hash for anything), we could then decide to relax the
> scoping.
>
I think that would be too major a change to spring on people in a point
release; we're likely going to be stuck with whatever we decode here for
several years. All the use cases I've heard for hashes assume they'll have
scope/resource like semantics, not "augmentations are local" semantics--am I
missing a slew of use cases which depend on augmentations being local?
-- Markus
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
