Luke Kanies <[EMAIL PROTECTED]> writes:
> On Jul 20, 2008, at 6:58 PM, Daniel Pittman wrote:
>> Luke Kanies <[EMAIL PROTECTED]> writes:
>>> On Jul 20, 2008, at 3:59 AM, Daniel Pittman wrote:
>>>> Luke Kanies <[EMAIL PROTECTED]> writes:
>>>>> Why don't you try the recursive setting of instance variables and
>>>>> see
>>>>> how it performs? It might be sufficient.
>>>>
>>>> So, as expected this had the side-effect of making it impossible to
>>>> detect when an undefined variable was used in a template. This was
>>>> quite a loss, in my opinion, and something I would rather not give
>>>> up.
>>>
>>> Why would that be the case? Ruby has a builtin 'defined?' method:
>>
>> Ah, my explanation was unclear:
>>
>> ...this had the side-effect of making it impossible for Puppet to
>> automatically detect, and signal an error, when the template used an
>> undefined variable.
>>
>> At the moment a reference to an undefined value will raise an
>> exception,
>> failing the catalog build.
>>
>> Using an undefined variable, after the change, will simply return
>> 'nil'. That gives up this (IMO, desirable) behaviour of treating an
>> undefined value as an error.
>>
>>
>> So, yes, the author could manually test every value was defined, but a
>> typographic error in the template would go unnoticed.[1]
>>
>> What would be list is *automatic* checking.
>
> Hmm, I think this objection isn't valid, because it's an objection to
> Ruby, rather than Puppet's use of Ruby. That is, Ruby doesn't fail
> when you use an undefined variable, so Puppet probably shouldn't either.
I actually disagree: the puppet language isn't Ruby, for good reason,
and I think it is reasonable that the template language is also "not
Ruby". (Otherwise I wouldn't be arguing, I guess.)
> I know in my own programming I'm very conscious of the difference
> between defined, nil, and having a value.
So am I, but I know from long experience that this isn't going to be the
case for everyone. I also know that I do occasionally make mistakes,
and without a static checker I risk discovering the problem at runtime,
as an invalid configuration is pushed out and takes down my network...
> Given that your code directly exposes a lot more information to the
> user, I like it better, and I'd actually like to switch to it.
The member variables stuff? Sure. I will recheck your last round of
comments and polish up that patch then, I guess.
The biggest remaining change, testing, is going to be hard: I have to
drop around half the existing template tests because they will no longer
signal errors when unused variables are referenced.
> It's more like how other applications use templating (instance
> variables rather than method_missing hacks), and you can do things
> like list available variables, check whether they're defined, and a
> good bit more. The method_missing hack requires that all of this
> functionality be provided piecemeal, as methods in the template
> wrapper class.
*nod* That is a reasonable point.
> For the record, I came up with this hack while semi-drunk and talking
> to the CTO of Red Hat -- I was talking about how we were going to add
> templating as soon as I could come up with a means of doing so, and as
> I said it, I came up with this mechanism. So, it was created in a fit
> of inspiration rather than one of those long-term visions, and it's
> always felt a bit hackish.
I confess that my distaste for Ruby has increased as a result of this:
it has terrible, inconsistent meta-programming support, and has made me
very grumpy.
What I /really/ want is 'missing_instance_variable', which has all the
advantages of the current code with none of the drawbacks. Sadly, no
such facility is available, so we end up with something nasty where we
have to give up on *something* to make this all work.
Anyway, enough whining. I will look at adding more testing to my member
variable branch, then sending through and updated patchset.
Regards,
Daniel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
