The Json_table_nested_path lives only inside the Table_function_json_table and that last one is the only class that manipulates the Json_table_nested_path internals. Using methods in your version, but it's the only class using these methods anyway. So to me it's seems more honest to declare classes as friends so we explicitly allow access to the internals to that one class and disallow to everyone else. But yes, it's rather the matter of taste. Best regards. HF On Fri, Mar 12, 2021 at 2:33 AM Sergey Petrunia <sergey@mariadb.com> wrote:
On Sat, Mar 06, 2021 at 01:13:53AM +0400, Alexey Botchkov wrote:
Hi, Sergei!
I pushed the patch to the feature branch for you to take a look. The patch you proposed http://lists.askmonty.org/pipermail/commits/2021-March/014492.html I liked and adapted with one exception. The nested paths list is built using the **last_sibling_hook instead of *cur_last_sibling. That seems to me nicer and doesn't produce that many repeating lines in the code.
On the other hand, use of "last_sibling_hook" makes Table_function_json_table to be aware about the internals of Json_table_nested_path (you had to make it a friend class).
And the price to pay for complete isolation was the if-else in start_nested_path(), with two lines in either branch. So I would still say that the suggested solution was cleaner.
I don't consider this to be a showstopper issue, though.
BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://petrunia.net