Hi tim
what was the result of you chat?
Because to me I would go for the first solution because in any case
you would have to modify the sprintsIn: method if the argument is
really changing so I do not see the point to carry around and extra
arguments to all the methods.
stef
On Mon, Jun 12,
2017-06-13 7:39 GMT-03:00 Tim Mackinnon :
> Phil - to be clear, I think your underlying implementation is great - it
> provides a great building block.
>
> However, just as with databases, when you build something higher level on
> top - the question comes up about how much you
Phil - to be clear, I think your underlying implementation is great - it
provides a great building block.
However, just as with databases, when you build something higher level on top -
the question comes up about how much you hide that retrieval mechanism. The
GTInspector argument is an
A dynamic variable could work too.
But domain objects are somewhat hard to do in my view because we are
dealing with an API that has tons of options and customizability in its
results + people can define their own types and fields.
That's why I went for a JiraBuilder thing that has a reference
Hello Tim,
2017-06-12 16:15 GMT-03:00 Tim Mackinnon :
> Hi - I’m after some ideas or maybe previous examples that might guide me in
> the best approach of wrapping a low level library (essentially the Jira
> connector that Phil demo’d at Pharo days this year).
>
> There are
Hi - I’m after some ideas or maybe previous examples that might guide me in the
best approach of wrapping a low level library (essentially the Jira connector
that Phil demo’d at Pharo days this year).
There are some low level commands that will fetch json arrays for you given a
“lira”