Re: [Boost-docs] [Gaea] Named optional attributes

Subject: Re: [Boost-docs] [Gaea] Named optional attributes
From: Matias Capeletto (matias.capeletto_at_[hidden])
Date: 2011-11-01 11:41:14

On Tue, Nov 1, 2011 at 11:22 AM, Joel de Guzman
<joel_at_[hidden]> wrote:
> On 11/1/2011 5:50 PM, Matias Capeletto wrote:
>>   [def [$ path [~width 100px] [~height 100px]] ... ]
>> I know it is only syntax sugar because you could get the same effect
>> checking for nil in the body but I think this will be a common
>> scenario that is good we support right away.
> Actually, I thought about that, wrote its spec just like you
> did, but later came to the opposite conclusion as you have.
> Do you really think that this is a common scenario? In the case
> of the images, for example, a default does not make sense.
> What other use cases do you think will this make sense?
> Is it really that common?

It felt so common before reading this...
Trying to think about examples and experience such a difficult time to
came up with good ones is not a good sign. Maybe something like [def
[code body [~lang C++]] ... ]... it was the best I could think of. You
are right, maybe is not that necessary after all.

> Also, that would prevent us from detecting if the user did
> pass something or not because there will always be a value
> instead of an /optional/ value. Not sure if that matters
> though.

If you want the real optional value instead of nil, you can still
consider that if not default value is provided then is undefined.

> I don't have a strong opinion on this. Your thoughts?

If you do not define the value of an undefined optional parameter as
nil, then the spec needs to be augmented to treat this new thing. For
example with an [decl [defined symbol]]. But if we go this way, we
should also find clear examples where the nil default is not enough.

Talking about optional arguments, have you think about using it for
the if template?

  [if [condition][

Just playing in this case, I also like how it is currently defined.


This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:41 UTC