Are you sure you can't rework your code to *not* copy data 5x? I assume
you're doing conversion between formats, so the output will be something
completely else anyway. No need to work in-place then (which I assume is
the reason you're dup-ing).
-- niklas
···
On Thu, 2011-02-24 at 06:46 +0900, Stefan Salewski wrote:
On Feb 23, 2011, at 14:00 , niklas | brueckenschlaeger wrote:
Are you sure you can't rework your code to *not* copy data 5x? I assume
you're doing conversion between formats, so the output will be something
completely else anyway. No need to work in-place then (which I assume is
the reason you're dup-ing).
# here's another, not for <=1.8.6 @scr, @png, @pdf, @svg, @ps = 5.times.map { @output.dup }
But I think the original 5 lines is clearer
Thanks. I agree, but I am still learning Ruby, so I like to see what is
possible. And I like to save some lines of code. On the other hand,
plain code is easier to understand and can easier converted to other
languages, I know.
···
On Thu, 2011-02-24 at 06:58 +0900, Brian Candler wrote:
The code is related to handling configuration files, I have a basic
configuration set, a hash called @output. And variants for on screen,
pdf, png export. I can avoid duplicates, of course, if I look at the
basic hash and at the special variants each time. But that is a little
bit more complicated and consumes more time, which is not really good.
All that is related to a graphical editor -- I have to clean up the code
a bit, it will become available on my page some time, then we can
discuss improvements. A tiny part related to cairo drawing is already
there:
The code is related to handling configuration files, I have a basic
configuration set, a hash called @output. And variants for on screen,
pdf, png export.
In that case, I'd say you'd be better off avoiding all the separate
instance variables for each variant, and make it data-driven. Then you
can interate over the variants, which will naturally avoid the repeated
code.
Now you have @configs[:scr], @configs[:png] etc, all pointing to
separate copies of @output. And if you want to add another format in
future, it's a trivial change.
(Aside: please do not post variants of this code using 'inject', because
it's stupid here. You know who you are. Thank you.)
Stefan Salewski wrote in post #983443:
> The code is related to handling configuration files, I have a basic
> configuration set, a hash called @output. And variants for on screen,
> pdf, png export.
In that case, I'd say you'd be better off avoiding all the separate
instance variables for each variant, and make it data-driven. Then you
can interate over the variants, which will naturally avoid the repeated
code.
after that you can use pretty much any key you want
-- niklas
···
On Thu, 2011-02-24 at 18:09 +0900, Brian Candler wrote:
Now you have @configs[:scr], @configs[:png] etc, all pointing to
separate copies of @output. And if you want to add another format in
future, it's a trivial change.
(Aside: please do not post variants of this code using 'inject', because
it's stupid here. You know who you are. Thank you.)
> ok, try also something like,
>
> a,b,c,d,e =[x.dup]*5
That will cause a, b, c, d, e to point to the same objects, which
might result in an unexpected side effect.
Indeed, that was not what I wanted, I need 5 independent instances!
Brian Candler wrote:
Stefan Salewski wrote in post #983443:
The code is related to handling configuration files, I have a basic
configuration set, a hash called @output. And variants for on screen,
pdf, png export.
In that case, I'd say you'd be better off avoiding all the separate
instance variables for each variant, and make it data-driven. Then you
can interate over the variants, which will naturally avoid the repeated
code.
Now you have @configs[:scr], @configs[:png] etc, all pointing to
separate copies of @output. And if you want to add another format in
future, it's a trivial change.
(Aside: please do not post variants of this code using 'inject', because
it's stupid here. You know who you are. Thank you.)
Regards,
Brian.
I see the point, thanks.
Best regards,
Stefan Salewski
···
On Thu, 2011-02-24 at 11:10 +0530, Anurag Priyam wrote:
On Thu, Feb 24, 2011 at 1:40 PM, Anurag Priyam <anurag08priyam@gmail.com> > wrote:
>> ok, try also something like,
>>
>> a,b,c,d,e =[x.dup]*5
>
> That will cause a, b, c, d, e to point to the same objects,