Ah ok, just saw Marcus's answer, so most of my assumptions were correct. I
would still say, there are many ways to achieve the same thing in
programming. With the kind of flexibility, that python provides, the 'many
ways' becomes 'so many ways'.
Coming back to some of the points that Ian raised:
> Readability is a perfectly valid goal to seek but I
find maintainability is often overlooked.
IMHO more readable code is more maintainable. Readability goes hand in hand
with maintainability. In fact, I very much agree that code lasts longer
than an author and if you write readable code it will be easier to read and
understand for the people after you are gone and are not available to
explain why you did what. If by maintainability you meant actually
extensibility, then it is a completely different aspect.
> In driving to a solution avoiding the additional markup (as in my
solution or in json/XML) you've likely put yourself (and too often your
team after you've left) in a place where you'll need to rewrite the
function for future feature requests.
If you read my previous posts in this threads, you will see that I clearly
mentioned that getting input is an administrative logic. In fact, I
provisioned for it and alluded to Marcus about it. Here's what I wrote:
- Right in the beginning, we parse the string in a single line, keeping
the administrative logic out from the rest of our business code. You can
easily replace this single line with whatever parser you want.
This means that the code that is responsible for creating nodes should not
worry itself with how it is getting the data in, JSON or YAML. And the
parser, whichever it is, should not worry about what is going to happen to
data it outputs. any good architecture should take care of this point.
Making components decoupled and flexible. Good architecture does not only
apply to huge libraries or big project, it should be given thought to every
single small quantum of code, a function and even inside parts of a
function. I did not avoid the input data structure, I simply did not work
on that part as was not required my Marcus originally. Even then, I
separated the code so that in my implementation, nowhere it does rely on
whether I choose JSON or YAML or some other markup. If ten years later,
somebody wants to use my implementation, with JSON the only change it would
require is to change the first line of my code.
On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson <konstrukt...@gmail.com>
wrote:
> Thanks Ian!
>
> Some notes.
>
> - The implementation is up for grabs, but I'd like to keep the interface
> of the function; that is, passing a single string with indentation for
> hierarchy.
> - Performance is not important here, because (1) the function is only
> being used in example code, where the call itself should fall into the
> background and (2) creating a hierarchy can safely take a few hundred
> milliseconds if it means more readable code.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python_inside_maya+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_
> KwK32ZxRZeo%3DatdrKgdkeThNzRw%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q9Z0pGYBBBjYZhYbLDHKMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
