Received: by 10.236.76.133 with SMTP id b5mr16640426yhe.0.1335121702827;
        Sun, 22 Apr 2012 12:08:22 -0700 (PDT)
X-BeenThere: erector@googlegroups.com
Received: by 10.236.119.195 with SMTP id n43ls7806067yhh.3.gmail; Sun, 22 Apr
 2012 12:08:22 -0700 (PDT)
Received: by 10.236.192.230 with SMTP id i66mr1531515yhn.4.1335121702297;
        Sun, 22 Apr 2012 12:08:22 -0700 (PDT)
Date: Sun, 22 Apr 2012 12:08:21 -0700 (PDT)
From: tobyo <toby.oconn...@gmail.com>
To: erector@googlegroups.com
Message-ID: <6822007.2121.1335121701618.JavaMail.geo-discussion-forums@ynmm9>
Subject: needs() shares default values among instances
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_2119_20474092.1335121701612"

------=_Part_2119_20474092.1335121701612
Content-Type: multipart/alternative; 
	boundary="----=_Part_2120_6155479.1335121701617"

------=_Part_2120_6155479.1335121701617
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The latest commit to needs.rb seems to indicate that such an issue was 
fixed, but here's what occurs with version 0.9.0.pre1

jirb
irb(main):062:0> require 'rubygems'
=> false
irb(main):063:0> require 'erector'
=> true

irb(main):066:0> class Sprocket < Erector::Widget
irb(main):066:0>   needs :foo => 'A'
irb(main):067:1>   def content
irb(main):068:2>     @foo.succ!
irb(main):069:2>     p "@foo is #{@foo}"
irb(main):070:2>   end
irb(main):071:1> end
=> nil

irb(main):072:0> x = Sprocket.new
=> #<Sprocket:0x1649b1a @foo="A", @_block=nil, @_assigns={}>
irb(main):073:0> x.to_html
=> "<p>@foo is B</p>"
irb(main):074:0> x.to_html
=> "<p>@foo is C</p>"
irb(main):075:0> x.to_html
=> "<p>@foo is D</p>"

irb(main):076:0> y = Sprocket.new
=> #<Sprocket:0x46fef3 @foo="D", @_block=nil, @_assigns={}>
irb(main):077:0> y.to_html
=> "<p>@foo is E</p>"


This is particularly problematic if you wanted to assign an empty array or 
hash as the default.  The workaround is to avoid needs() default values and 
instead assign defaults in a constructor.

Perhaps this is more of a feature than a bug, but I think it's rare one 
would want to have multiple widget instances point to the same instance 
unless it is something like a formatter class or something to that effect. 
It would generally make more sense to dup() each default value.

Perhaps it would be nice to allow passing a proc/lambda to needs() that is 
evaluated for each new Widget instance. Of course, that doesn't let you 
directly default to a proc.

needs :a_string => proc { 'A' }
needs :a_proc => proc { proc{ 'A' } }

Thoughts?

------=_Part_2120_6155479.1335121701617
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The latest commit to needs.rb seems to indicate that such an issue was fixe=
d, but here's what occurs with version 0.9.0.pre1<br><br>jirb<br>irb(main):=
062:0&gt; require 'rubygems'<br>=3D&gt; false<br>irb(main):063:0&gt; requir=
e 'erector'<br>=3D&gt; true<br><br>irb(main):066:0&gt; class Sprocket &lt; =
Erector::Widget<br>irb(main):066:0&gt;&nbsp;&nbsp; needs :foo =3D&gt; 'A'<b=
r>irb(main):067:1&gt;&nbsp;&nbsp; def content<br>irb(main):068:2&gt;&nbsp;&=
nbsp;&nbsp;&nbsp; @foo.succ!<br>irb(main):069:2&gt;&nbsp;&nbsp;&nbsp;&nbsp;=
 p "@foo is #{@foo}"<br>irb(main):070:2&gt;&nbsp;&nbsp; end<br>irb(main):07=
1:1&gt; end<br>=3D&gt; nil<br><br>irb(main):072:0&gt; x =3D Sprocket.new<br=
>=3D&gt; #&lt;Sprocket:0x1649b1a @foo=3D"A", @_block=3Dnil, @_assigns=3D{}&=
gt;<br>irb(main):073:0&gt; x.to_html<br>=3D&gt; "&lt;p&gt;@foo is B&lt;/p&g=
t;"<br>irb(main):074:0&gt; x.to_html<br>=3D&gt; "&lt;p&gt;@foo is C&lt;/p&g=
t;"<br>irb(main):075:0&gt; x.to_html<br>=3D&gt; "&lt;p&gt;@foo is D&lt;/p&g=
t;"<br><br>irb(main):076:0&gt; y =3D Sprocket.new<br>=3D&gt; #&lt;Sprocket:=
0x46fef3 @foo=3D"D", @_block=3Dnil, @_assigns=3D{}&gt;<br>irb(main):077:0&g=
t; y.to_html<br>=3D&gt; "&lt;p&gt;@foo is E&lt;/p&gt;"<br><br><br>This is p=
articularly problematic if you wanted to assign an empty array or hash as t=
he default.&nbsp; The workaround is to avoid needs() default values and ins=
tead assign defaults in a constructor.<br><br>Perhaps this is more of a fea=
ture than a bug, but I think it's rare one would want to have multiple widg=
et instances point to the same instance unless it is something like a forma=
tter class or something to that effect. It would generally make more sense =
to dup() each default value.<br><br>Perhaps it would be nice to allow passi=
ng a proc/lambda to needs() that is evaluated for each new Widget instance.=
 Of course, that doesn't let you directly default to a proc.<br><br>needs :=
a_string =3D&gt; proc { 'A' }<br>needs :a_proc =3D&gt; proc { proc{ 'A' } }=
<br><br>Thoughts?<br>
------=_Part_2120_6155479.1335121701617--

------=_Part_2119_20474092.1335121701612--