Re: [Openembedded-architecture] [PATCH] data_smart: Drop default expand=False to getVar [API change]

From: Christopher Larson <clarson@kergoth.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-architecture
	<openembedded-architecture@lists.openembedded.org>,
	bitbake-devel <bitbake-devel@lists.openembedded.org>,
	Otavio Salvador <otavio.salvador@ossystems.com.br>
Subject: Re: [Openembedded-architecture] [PATCH] data_smart: Drop default expand=False to getVar [API change]
Date: Wed, 3 Feb 2016 09:52:03 -0700	[thread overview]
Message-ID: <CABcZANm03MMuh4k1Lxi=PaXTC+j2uWMiruq=8fsnadKvQBsO0Q@mail.gmail.com> (raw)
In-Reply-To: <1454517490.27087.199.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

On Wed, Feb 3, 2016 at 9:38 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2016-02-03 at 09:29 -0700, Christopher Larson wrote:
> > >  The actual getVar syntax on the other handy is more than cosmetic,
> > > people don't understand what this "True" they keep adding means, or
> > > why
> > > they need it. You tend to know when you don't want expansion on the
> > > other hand. So a cleaner syntax which does what the user most
> > > likely
> > > needs is more than cosmetic.
> > I'd agree with that, passing booleans as arguments sucks all around,
> > since it loses context. *If* someone is going to do it, it's best to
> > pass it with the argument name in keyword form in the caller, and
> > obviously we don't want to do that here.
> >
> > That said, I'm rather inclined toward thinking about alternative
> > DataSmart APIs in general, in the long term. For example, it's a
> > MutableMapping, so it acts dict-like, so we should be able to use
> > .get() and get an expanded value, and then the case would line up
> > with PEP8 (CamelCase for functions is frowned upon). I.e. we could
> > have get() and get_unexpanded().
>
> I'm just thinking out loud here, I think the above is worth seriously
> considering. One big advantage "getVar" has is that its pretty unique
> and the python parsing code therefore doesn't get a lot of false
> positives with function names. "get" on the other hand, I can see being
> a nightmare.


That's a good point, I'll admit I didn't think about the codeparsing in
that regard. I wonder how much work it'd be to track what variable(s) hold
DataSmart instances.. we know 'd' starts that way, that's an assumption we
can make, but it wouldn't traverse createCopy().. *Ponders*
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2555 bytes --]