Re: [tarantool-patches] Re: [PATCH v2 03/10] yaml: introduce yaml.decode_tag

[Konstantin Osipov <kostja@tarantool.org>]

* Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [18/05/24 23:53]:
> Fixed on the branch. See the complete patch at the end of the letter. But
> IMO now decode() function looks ugly. Option 'tag_only' requires to
> create a Lua table on each call with the single option when it is needed.
> And 'tag_only' itself is very strange. It is the same as we would make
> message pack types as options like this:
> 
> - msgpack.decode_array/unsigned/string ...
> + msgpack.decode(..., {array/unsigned/string... = true})
> 
> But as you wish.

No, there is a difference. With tags, you still potentially decode
entire stream, the option specifies that you're only interested in
tags. With msgpack.decode_array() you explicitly request to decode
a single element on the stream, and it must be in front of the
stream.

Re extra overhead to build a Lua table, passing options as named
arguments in a single table is our standard convention. If I were
worried about performance, I'd be looking at
https://github.com/tarantool/tarantool/issues/30 

Notice how old it is. No likes, no upvotes. I hope now that you're
no longer a student we can finally put the issue of premature
optimization at rest :)

But I have no strong opinion about this actually. It was only a
suggestion, not something I would fight for. If you want to put
encode_tagged/decode_tagged back, I'm OK with it - we can add
options to encode()/decode() any time we want.

-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov