Add Cellulate, a late init Celluloid mixin #126

Closed
wants to merge 2 commits into
from

Projects

None yet

2 participants

@sempervictus

This commit adds Cellulate, a mixin which can be used to convert
an existing object into a Celluloid Actor proxy.

Either mix in, or extend your object with Cellulate and assign it
the result of its own "cellulate" call. See cellulate.rb in
examples for code sample.

TODO:
testing
create Cellulate::IO and DCellulate for the corresponding
libraries.

RageLtMan added some commits Nov 27, 2012
RageLtMan Add Cellulate, a late init Celluloid mixin
This commit adds Cellulate, a mixin which can be used to convert
an existing object into a Celluloid Actor proxy.

Either mix in, or extend your object with Cellulate and assign it
the result of its own "cellulate" call. See cellulate.rb in
examples for code sample.

TODO:
testing
create Cellulate::IO and DCellulate for the corresponding
libraries.
196d543
RageLtMan Namespace, safety switch, and big warning sign.
Add a warning with an explanation and example as to why this is
dangerous.
Move Cellulate into Celluloid namespace.
Make :cellulate private.
Update example.
ae84639
@tarcieri
Celluloid member

I'm not sure this is a good idea... from your comments you seem to have gathered as much yourself ;)

@sempervictus

In principle, i wholeheartedly agree with your approach to making threaded operation as safe and grunt proof as possible. In the real world, i've been running into a lot of problems integrating Celluloid and its derivatives into existing code where we deal with conditional/staged object construction or a pre-existing threading model.

The first problem is solved outright here, and the button for this is bright red with clearly marked warning signs.
The second problem needs much more work, but is partially resolved here as this allows us to replace complicated thread logic (under the proper conditions) with an actor proxy via extension and a method call. Aside from simplification this approach allows for compatible behavior between new objects designed with Celluloid in mind, and legacy code which is expensive to rewrite from the ground up (the proper way).

I suppose the resolution to this PR depends on what we think is a "good idea." Do you favor principle and proper development methodology, or wider adoption and ease of integration for an existing codebase or users with edge cases requiring late init?

If the decision is a painful one, we could provide cellulate and its spawn (IO, dcell, etc) as a separate gem, and avoid my polluting your code. Though i'm not sure how much that would assist with adoption, those in real need should be able to find it.

@tarcieri
Celluloid member

I think I'd probably prefer a separate gem. This isn't an approach I'd really like to encourage, but one that might make sense for people who are doing retrofits.

As far as steering people towards it, that can be done on the mailing list / IRC channel.

@tarcieri
Celluloid member

Per our discussion on IRC, I think this is better served by a separate gem. We can put it under the Celluloid project.

@tarcieri tarcieri closed this Dec 12, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment