Skip to content

Request: access with default value. #353

Closed

Description

@maleafl

Hi everyone!

I would suggest to provide new member functions

    template <typename T>
    T operator ()(const typename object_t::key_type& key, const T &fallback) const
    {
        const auto it = find(key);
        if (it == end() || it.value().is_null())
        {
            return fallback;
        }
        else
        {
            return at(key);
        }
    }

    string_t operator ()(const typename object_t::key_type& key, const string_t &fallback) const 
    {
        return operator()<string_t>(key, fallback);
    }

    template <typename T>
    T operator ()(const typename object_t::key_type& key, const T &fallback)
    {
        const auto it = find(key);
        if (it == end() || it.value().is_null())
        {
            return (*this)[key] = fallback;
        }
        else
        {
            return (*this)[key];
        }
    }

    string_t operator ()(const typename object_t::key_type& key, const string_t &fallback)
    {
        return operator()<string_t>(key, fallback);
    }

I use those for convenient accesses to numbers, strings, vectors and maps in a json object with default values.

Further, i use

    reference operator()(const typename object_t::key_type& key)
    {
        return (*this)[key];
    }

    value_type operator()(const typename object_t::key_type& key) const
    {
        if (find(key) == end())
        {
            return value_type();
        }
        else
        {
            return (*this)[key];
        }
    }

for more consistent code look when using the functions above.

What do you think?

Greetings

Activity

  1. nlohmann commented on Nov 11, 2016

    @nlohmann
    Owner

    @SmoofBullet Did you have the time to look at the value function?

  2. zumm commented on Nov 14, 2016

    @zumm

    @nlohmann method "value" helps to avoid outing of range only. If requested field exists, but has different type then this method throws exception. Such behavior is undesirable.

  3. nlohmann commented on Nov 14, 2016

    @nlohmann
    Owner

    There has been quite a discussion about this, see #278.

  4. zumm commented on Nov 14, 2016

    @zumm

    So this functional will be implemented in release 3.0.0? Great (apropos when it happens?)!

  5. nlohmann commented on Nov 14, 2016

    @nlohmann
    Owner

    #278 is planned for the 3.0.0. This release will most likely not be ready this year.

    If you can live with the proposal in #278, I would like to close this ticket.

  6. zumm commented on Nov 15, 2016

    @zumm

    Yes, i can. :) But could starter of this ticket?

  7. nlohmann commented on Nov 15, 2016

    @nlohmann
    Owner

    Oh, sorry. @SmoofBullet What do you think?

  8. maleafl commented on Nov 15, 2016

    @maleafl
    Author

    I think the solution will work for me, although im not sure whether the value function should be restricted to object types. If i provide a default value, i would not mind if the caller passed me the wrong type (something different than object).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions