[GSOC2018][RubyPlotGR][26-06-2018]Shifted plotting to a different Class

[Pranav Garg]

Greetings,

As per the discussion yesterday, I ported the all the plotting functionalities to a different class (I have called it PlotSpace so that it is not confused with GR Workspace). I like the idea that FIgure class contains all the information about a Figure and then calling separate instances to actually plot them.

However, I do not like the idea of passing a lot of Variables for instantiation of this class .

There will be more variables that will be added, instantiating them all seems redundant.

I was going through the first chapter of the metaprogramming book and I have a hunch that the answer to the same lies over there. Any topic that I can fast-track to that might help me clear this problem?

The spec files have helped me shape the Library to its current shape (Now I see the logic behind TDD, initially I thought that Tests are there to confirm that things are working properly, Guess I did not pay emphasis to 'Driven'). So before moving further and introducing new plots I will be working on specs and look for potential candidates for the equal_files function to pass the specs.

I will be saving and deleting the temporary files created during testing. Sameer, You told me not to use the system commands for that as they do not work across platforms. You suggested an alternative but I forgot about it.😅 Can you please reiterate?

https://github.com/pgtgrly/GRruby-extension/commit/dcd49ac479aeaa3eedde22c334aea715808fe617

https://github.com/pgtgrly/GRruby-extension/commit/9a4ace17e4f1dc27fddc0d450f0cea4311be4623

Regards

PG

[John Woods]

Why do you need to pass it all of those variables? Just pass it a single reference to the Figure, and let it look in the Figure for those things. It doesn't need to copy all of the data, either — it can just always refer back to the one reference to the figure.

I'd suggest calling it PlotSpace (in plot_space.rb) instead of Plotspace. Ruby likes CamelCase, remember? Plotspace has too many possible parses — PlotSpace, PlotsPace, PlotspAce, etc. We want your code to be so clear that it doesn't need comments. (Don't actually stop using comments, but that's the guiding rule I use for writing my code, and it helps.)

I'll put some more comments on your commits.

On Tue, Jun 26, 2018 at 9:02 AM Pranav Garg <prana...@gmail.com> wrote:

Greetings,

As per the discussion yesterday, I ported the all the plotting functionalities to a different class (I have called it PlotSpace so that it is not confused with GR Workspace). I like the idea that FIgure class contains all the information about a Figure and then calling separate instances to actually plot them.

However, I do not like the idea of passing a lot of Variables for instantiation of this class .

There will be more variables that will be added, instantiating them all seems redundant.

I was going through the first chapter of the metaprogramming book and I have a hunch that the answer to the same lies over there. Any topic that I can fast-track to that might help me clear this problem?

The spec files have helped me shape the Library to its current shape (Now I see the logic behind TDD, initially I thought that Tests are there to confirm that things are working properly, Guess I did not pay emphasis to 'Driven'). So before moving further and introducing new plots I will be working on specs and look for potential candidates for the equal_files function to pass the specs.

I will be saving and deleting the temporary files created during testing. Sameer, You told me not to use the system commands for that as they do not work across platforms. You suggested an alternative but I forgot about it.😅 Can you please reiterate?

https://github.com/pgtgrly/GRruby-extension/commit/dcd49ac479aeaa3eedde22c334aea715808fe617

https://github.com/pgtgrly/GRruby-extension/commit/9a4ace17e4f1dc27fddc0d450f0cea4311be4623

Regards

PG

[Pjotr Prins]

Having many parameters is a code smell.

The way to think about these things is to think about state. What
state are you passing around that is really needed. State typically
can go in a C struct or Ruby Hash variable, tuple, even array. Pass
that around.

I am not too fond of Ruby classes for state - as they risk being
tightly coupled with code. Code and data/state should be separate and
can be independent of each other. I.e., more of a functional
programming paradigm. To understand that better listen to some of Rich
Hickeys talks (Clojure).

Metaprogramming should only be used when there is no other option or
when it is really, really elegant - like OpenStruct (something you can
use too for state). Too quickly metaprogramming becomes like magic
and you end up dealing with hard to maintain code.

Pj.

On Tue, Jun 26, 2018 at 10:15:12AM -0700, John Woods wrote:
> Why do you need to pass it all of those variables? Just pass it a
> single reference to the Figure, and let it look in the Figure for those
> things. It doesn't need to copy all of the data, either — it can just
> always refer back to the one reference to the figure.
> I'd suggest calling it PlotSpace (in plot_space.rb) instead of
> Plotspace. Ruby likes CamelCase, remember? Plotspace has too many
> possible parses — PlotSpace, PlotsPace, PlotspAce, etc. We want your
> code to be so clear that it doesn't need comments. (Don't actually stop
> using comments, but that's the guiding rule I use for writing my code,
> and it helps.)
> I'll put some more comments on your commits.

> On Tue, Jun 26, 2018 at 9:02 AM Pranav Garg <[1]prana...@gmail.com>

> wrote:
>
> Greetings,
> As per the discussion yesterday, I ported the all the plotting
> functionalities to a different class (I have called it PlotSpace so
> that it is not confused with GR Workspace). I like the idea that FIgure
> class contains all the information about a Figure and then calling
> separate instances to actually plot them.

> Blank Diagram(2).png
> However, I do not like the idea of passing a[2] lot of Variables for

> instantiation of this class .
> There will be more variables that will be added, instantiating them all
> seems redundant.
> I was going through the first chapter of the metaprogramming book and I
> have a hunch that the answer to the same lies over there. Any topic
> that I can fast-track to that might help me clear this problem?
> The spec files have helped me shape the Library to its current shape
> (Now I see the logic behind TDD, initially I thought that Tests are
> there to confirm that things are working properly, Guess I did not pay
> emphasis to 'Driven'). So before moving further and introducing new
> plots I will be working on specs and look for potential candidates for

> the [3]equal_files function to pass the specs.

> I will be saving and deleting the temporary files created during
> testing. Sameer, You told me not to use the system commands for that as
> they do not work across platforms. You suggested an alternative but I
> forgot about it.😅 Can you please reiterate?

> [4]https://github.com/pgtgrly/GRruby-extension/commit/dcd49ac479aeaa3ee
> dde22c334aea715808fe617
> [5]https://github.com/pgtgrly/GRruby-extension/commit/9a4ace17e4f1dc27f
> ddc0d450f0cea4311be4623
> Regards
>
> PG
>
> --
> You received this message because you are subscribed to the Google
> Groups "SciRuby Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [6]sciruby-dev...@googlegroups.com.
> For more options, visit [7]https://groups.google.com/d/optout.
>
> References
>
> 1. mailto:prana...@gmail.com
> 2. https://github.com/pgtgrly/GRruby-extension/blob/dcd49ac479aeaa3eedde22c334aea715808fe617/lib/rubyplot/scripting.rb#L83
> 3. https://github.com/pgtgrly/GRruby-extension/blob/dcd49ac479aeaa3eedde22c334aea715808fe617/spec/scripting_layer/single_plot_graph_spec.rb#L23
> 4. https://github.com/pgtgrly/GRruby-extension/commit/dcd49ac479aeaa3eedde22c334aea715808fe617
> 5. https://github.com/pgtgrly/GRruby-extension/commit/9a4ace17e4f1dc27fddc0d450f0cea4311be4623
> 6. mailto:sciruby-dev...@googlegroups.com
> 7. https://groups.google.com/d/optout

[John Woods]

Yeah. Metaprogramming doesn't have the solution to your current problem. (Though I'm a lot less conservative about it than Pjotr.) Mostly I suggested the metaprogramming book because I think it'll give you some good ideas about how to write your Rubyesque API.

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sameer Deshmukh]

You should use the ruby `File` module for file operations.