Release Candidate 2 (beta version)

Yesterday, we released Jackbox RC2.

With this release we have concluded the upgrade of the inheritance model and are gearing up for version 1.0.  The inheritance model in Jackbox now has to concurring aspects.  First, there is the now well known Versioned Inheritance.  This form of inheritance takes all pre-existing methods and makes them part of your new Injector version for use.

With RC2 however, we have added a new aspect to this design pattern. We have called it Just-in-Time Inheritance for lack of a better term (taking suggestions), and because it self-injects ancestor function just at it is need by your code.  In this way our modular closures are endowed now with a similar model of inheritance as you would find in classes, all happening in the mix-in however.

Also in this release we have made some improvements to the VMC (virtual method cache), numerous updates, introduced more examples, and once again updated the documents.  One major perhaps incompatible change is the reversal in the ordering of how injectors are added and presented.  We are now following in line with Ruby which handles ancestor precedence in a left to right order instead of the other way around. 

Once again we would like to Thank everyone who has shown their support through the numerous emails we have received and, also once again we hope we have met with your expectations.

Please visit us: http://jackbox.us


Thank you, kindly,

Lou

JIT Inheritance

This flavor of the inheritance model allows our modular closures to have similar properties to the inheritance of classes. With it you can expect to have access to its super members as part of the call, just like you would with classes. In addition to the inheritance resulting from versioning, JIT inheritance presents a more complete scenario adding color to the picture painted by code injectors. The key takeaway here is this: Code Injectors are mix-ins that share a similar inheritance model with classes. You can version them to gain access to versioned inheritance or you can override its members to access an ancestor chain comprised of all previous tags. As always we will use some example code to illustrate:

# # Our Modular Closure # Tag1 = trait :Tagger do def m1 1 end def m2 :m2 end end # # Normal Versioned Injector inheritance # Tagger do def other 'other' # -- same ancestors as before end end expect(Tagger().ancestors).to eql( [Tagger()] ) # test it o = Object.new.extend(Tagger()) # inherited o.m1.should == 1 o.m2.should == :m2 # current o.other.should == 'other' # # JIT inheritance # Tag2 = Tagger do def m1 # The :m1 override invokes JIT inheritance super + 1 # -- Tag1 is summoned into ancestor chain end # -- allows the use of super def m3 'em3' end end # test it p = Object.new.extend(Tag2) # JIT inherited p.m1.should == 2 # regular inheritance p.m2.should == :m2 p.m3.should == 'em3' p.other.should == 'other' expect(Tagger().ancestors).to eql( [Tagger(), Tag1] ) expect(Tag2.ancestors).to eql( [Tag2, Tag1] )

For more on this please see the rspec files in the project page or on the gem itself.

As always, Thank you kindly.