On Tue, Jan 03, 2017 at 23:41 +0100, you wrote:
> Is there a major show-stopper I am missing or is it just the fact that
> tuple support would be a new/untested language feature?
We'd need to hook them into a number of places across the interpreter.
For example there are various locations
> However, introducing tuples is a major piece by itself, and I'm
> reluctant to have the Broker changes depend on that.
>
> We could go the Broker::status() route for now and switch over to
> tuples later if/when we get them ...
Seems reasonable to me. However, I thought adding tuples would be
>> case type count as c:
>>
>
> I find that there's too much going on in a single line now. With the
> extra "type" keyword, my mind gets stuck figuring out precedence rules.
I agree, its hard to read and too much to type from my perspective.
> For "switch" that would imply:
>
> Yeah, I agree, don't like that version anymore either.
Ok, good. :-)
> case type count as c:
>
>
>
> What do you think of that? The additional "type" makes it visually
> clear what's it's about, and also helps the parser figure it out.
I find that there's too much going on
On Tue, Jan 03, 2017 at 17:22 +0100, you wrote:
> Something similar is already available in context of expiration
> callbacks for tables using multiple indices
Yeah, although that's indeed a one-off that would be hard to avoid
doing for more cases (for-loop over tables is another one).
I
On Tue, Jan 03, 2017 at 10:21 +0100, you wrote:
> > [result, value] = Broker::lookup(h, 42) # Returns [Broker::Result,
> > opaque of Broker::Data]
> > if ( result == Broker::SUCCESS ) ...
> I would prefer this solution, as it feels more natural coming from other
> languages like
On Mon, Jan 02, 2017 at 11:46 -0800, you wrote:
> That would mean we'd have new keywords: is, to, as. I find that's too
> confusing and think we should go with either "to" or "as" but not both.
Yeah, I agree, don't like that version anymore either. I have just
committed a first implementation
>>> [result, value] = Broker::lookup(h, 42) # Returns [Broker::Result,
>>> opaque of Broker::Data]
>>>
>>> if ( result == Broker::SUCCESS ) ...
>>
>> I would prefer this solution, as it feels more natural coming from other
>> languages like python.
>
> The key question is whether it
> > [result, value] = Broker::lookup(h, 42) # Returns [Broker::Result,
> > opaque of Broker::Data]
> >
> > if ( result == Broker::SUCCESS ) ...
>
> I would prefer this solution, as it feels more natural coming from other
> languages like python.
I like it as well because there's no
> We could also make the two different return values explicit:
>
> [result, value] = Broker::lookup(h, 42) # Returns [Broker::Result,
> opaque of Broker::Data]
>
> if ( result == Broker::SUCCESS ) ...
I would prefer this solution, as it feels more natural coming from other
languages
10 matches
Mail list logo
