[Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

This is python, so a get_last_error type API is really simple.  It can just
store the message in the tool class.

Also, I expect exists() to be cached for speed (based on the tool's args)
so when the tool doesn't exist it will need to store the message anyway, to
return it to future callers.  exists_error() just becomes an accessor for
that member var.  That basically means your double-negative version is no
different than the regular version in terms of implementation, and I think
the exists() + exists_error() API is nicer.

I don't really like the "error object", i.e. something that tests as False
but has a string value.

-- Gary



On Tue, Sep 9, 2014 at 9:56 AM, Kenny, Jason L <jason.l.kenny at intel.com>
wrote:

>  We have two options it seems:
>
>
>
> 1)      Add a exists_error_msg() like API.
>
> 2)      Or return an error object.
>
>
>
> Thoughts on 1):
>
> The main value with 1) is the exists is very simple in that it returns
> True or False.
>
>
>
> The main issue with it is that it is a bit more complex to implement a get
> last error like API. There are a number possible Issues such as memory
> waste can easily become an problem, Not having a simple API to use this for
> a tool writer I would see as being needed to help keep this logic easy to
> implement from the tool writers point of view and not adding resource and
> or correctness issues to SCons.
>
>
>
> Or the implementation may just need to re-test. So maybe the way to view
> this API is to instead view it like the inverse ie.. not_exist() ie this
> would return a string ( ie the message) when it does not exists and None
> when it does exists. Then exist would always be a impl like:
>
>
>
> def exists():
>
>    return not_exists()
>
>
>
> When the user wants to see why it does not exist they would call the
> not_exists() api. Which would provide a message. If used directly the logic
> of
>
>
>
> If !not_exists():  will work correctly ( yes it a double neg here.. ewww)
>
>
>
> This might be a way to do this, without a special object while keeping it
> simpler to implement.
>
>
>
> Thoughts on 2)
>
> The value of an error object is that it can work be easily made to work in
> basic testing cases, while allowing the returning of extra information such
> as information about what is wrong. It could be mixed with use of True, as
> in this case we most likely will not have a message to share whereas false
> we will.
>
>
>
> The main con to an error object is that the user has to return this
> object, which is a little more complex than returning False, but not as
> complex as trying to implement a GetLastError() like API.
>
>
>
> Jason
>
>
>
> *From:* Scons-dev [mailto:scons-dev-bounces at scons.org] *On Behalf Of *Gary
> Oberbrunner
> *Sent:* Tuesday, September 9, 2014 4:56 AM
> *To:* SCons developer list
> *Subject:* Re: [Scons-dev] This morning's WTF moment
>
>
>
>
>
> On Tue, Sep 9, 2014 at 4:03 AM, Jean-Baptiste Lab <
> jeanbaptiste.lab at gmail.com> wrote:
>
>  Or wouldn't it be enough to simply mandate that exists() return
> something that can be tested against True/False?
>
> If that's the case, wouldn't a bit of wrapping around and implementing the
> __eq__/__neq__ descriptors (possibly __cmp__) be good enough so that we can
> get to the error description when needed (if False) without breaking
> existing usages?
>
>
>
> I did think about that.  It's hard for me to imagine something that can
> test as false while still having a string value.  Not impossible, but
> pretty weird and a bit un-pythonic. I prefer simplicity over cleverness.
>  Still, if you have an idea, let me know.
>
>
>
> --
> Gary
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20140909/9e30d375/attachment.html>