After I read your proposal, I started writing a different proposal of my
own, until I realized that it was essentially the same idea (I was just
suggesting making all of the changes to undef itself) :)

So, instead of creating a whole new proposal, I'm going to build off of
yours.

Essentially you are getting the "correct" undef semantics by creating a new
"undef" that fits the puppet language a little better. By calling it
"default" it makes the intent of it a bit clearer to users. I would like to
take things a little farther:

  * Make references of non-existent variables (no binding in the chain of
scopes) illegal
  * Remove boxing (is this boxing? I would call this coercion) of default
to other types (default != "", default != 0, default + "string" and
"$a_default_var string" is an error)
  * default is truthy (undef is falsey)
  * Preserve that default as a parameter results in the default value of
the parameter
  * Introduce a "defaulting" operator much like perl's // (
http://perldoc.perl.org/perlop.html#Logical-Defined-Or)
  * Change facts and ENC variables to hashes in order to make dealing with
sometimes there, sometimes not variables easier

Now, given that you suggest making undef much stricter, which creates
compatibility problems, why bother with the default keyword? It seems like
we can achieve all of the same things that we are looking for by just
making undef stricter (remove automatic coercions, have it always show up
in ruby as nil). I like that calling it default makes intent for the case
of parameters clearer, but I fear that it ends up with a split
undefinedness problem like users of JavaScript encounter.

I think introducing the defined-or operator, we can make undef behave well,
make it turn into the default in parameters, and give users control over it
when they don't want that to happen.


Regards
> - henrik
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> puppet-dev+unsubscribe@**googlegroups.com<puppet-dev%[email protected]>
> .
> To post to this group, send email to [email protected].
> Visit this group at 
> http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev>
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>



-- 
Andrew Parker
[email protected]
Freenode: zaphod42
Twitter: @aparker42
Software Developer

*Join us at PuppetConf 2014, September 23-24 in San Francisco*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to