------art_64281_17505484.1150842470636
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 6/21/06, Jacob Fugal <lukfugl / gmail.com> wrote:
>
> On 6/20/06, Robert Dober <robert.dober / gmail.com> wrote:
> > The real problem is  requirement 2) of the OP,  instanciation of class B
> > shall only be possible in class A, e.g. in an instance of A, I do not
> think
> > this is possible, but I would not bet on it (not much).
> > It would already be nice to have some code which defends against the
> vanilla
> > instanciation of B outside of an A instance.
> > I did not yet come up with such a solution though.
> > Any ideas?
>
> One way would be to make B.new protected/private (similar to the way
> it's done in the Singleton mixin). But once you've done that, I'm not
> sure if there's a clean way to allow A to use that method -- Ruby
> doesn't have "friends" ala C++ (and I'm glad for it). Of course, once
> it's protected you *could* have A use send explicitly:


as can anyone else :(

  class B
>     class << self
>       protected :new
>     end
>   end
>
>   class A
>     def create_b
>       @b_objs << B.send(:new)
>     end
>   end
>
>   a = A.new
>   a.create_b # works fine
>   B.new # raises NoMethodError


B.send(:new) works
But I reasoned along the same lines as you, eventually I came up with an
anonymous class for B inside A
see my next post please.
If that pleases the OP I do not think the anonymous class is easily
accessible, of course one can always create an accessor to the anonymous
class inside A, :(

Cheers
Robert

This works, but it doesn't feel very clean :/
>
> Jacob Fugal
>
>


-- 
Deux choses sont infinies : l'univers et la bóŐise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

------art_64281_17505484.1150842470636--