Closures as modules

[addis_a]

Can closures be modules?

Well, Ladies and Gents we would like to introduce you to our new library
called Jackbox. It toys with the ideas of closures as modules. In it
you’ll find a series of new takes on ruby that are sure to spike you
interest. With it we have come up with a solution to the decorations
handicap in ruby and introduced some new constructs for code injection.

Please feel free to use it free of charge for now and to send us your
comments or inquiries.

Available from RubyGems.org. Just run: gem install jackbox.

Thank you

[louarnold]

Lou H. wrote in post #1164741:

Can closures be modules?

Why should they be?

Please feel free to use it free of charge for now and to send us your
comments or inquiries.

Please explain a bit more what this is about and why it is a good idea.
Also, if it is free of charge for now what are your plans in the future?

[louarnold]

Robert:

The design of the Ruby language already includes the basic closure as a
module criteria:

x = y

m = Module.new do

define_method :meth do
puts x
end

end

This criteria allows you to capture context from one object and store it
for later use. Our take on this simply extends this idea and enables us
to create on the fly injectors and decorators which are not part of the
standard for now.

The software is free to use. We may decide to have some licensing in
the future, or we might just make it open source.

Thank you, kindly.

[louarnold]

Lou H. wrote in post #1164819:

The design of the Ruby language already includes the basic closure as a
module criteria:

“criteria”? Maybe it’s because I am not a native speaker but I don’t
understand what the term means in this context.

x = y

m = Module.new do

define_method :meth do
puts x
end

end

You just demonstrate that blocks are closures. Instead of Module.new
there could be anything that is a call to a method that yields to a
block.

This criteria allows you to capture context from one object and store it
for later use.

That is a correct description of how closures usually work (apart,
again, from this “criteria” thingy).

Our take on this simply extends this idea and enables us
to create on the fly injectors and decorators which are not part of the
standard for now.

In what ways do modules make this easier? It would seem you just need a
set of methods and blocks in general to do the job.

[louarnold]

Criteria is just a term used to describe a reason for doing something.

So in this context our point is that the validity of this concept has
already been determined apriori by the language itself. We just want to
extend on that idea and make it better.

In what ways do modules make this easier? It would seem you just need a
set of methods and blocks in general to do the job.

Sure you can do the job with any Turing machine. But, what is the point
of having abstractions? These just tend to make the job easier for the
programmer. Our abstractions are those of code Injectors and
decorators.

Please refer to the readme file on GitHub or the gem itself for a more
detailed explanation.

Thank you, kindly.

[louarnold]

Lou H. wrote in post #1164921:

Criteria is just a term used to describe a reason for doing something.

That does not seem to make sense with your sentence:

The design of the Ruby language already includes the basic closure as a
module criteria:

If I apply your substitution then I get

“The design of the Ruby language already includes the basic closure as a
reason to use a module:”

If I need a closure then I use a block but not necessarily a module.
Reasons to use modules are different (reusing a set of methods in
multiple contexts, including classes and instances, tagging a class with
a type tag).

It is the other way round: if a module needs to close over some local
variables then I use a closure.

So in this context our point is that the validity of this concept has
already been determined apriori by the language itself. We just want to
extend on that idea and make it better.

see above

In what ways do modules make this easier? It would seem you just need a
set of methods and blocks in general to do the job.

Sure you can do the job with any Turing machine.

No, I said “methods and blocks”. This is trying to ridicule my question
by exaggerating my statement.

But, what is the point
of having abstractions? These just tend to make the job easier for the
programmer. Our abstractions are those of code Injectors and
decorators.

I still have not seen convincing reasons.

Please refer to the readme file on GitHub or the gem itself for a more
detailed explanation.

You never posted the link and searches [1] and [2] turned up multiple
results which do seem to lead to your code.

[1] Jackbox github at DuckDuckGo
[2] Jackbox github ruby at DuckDuckGo

[louarnold]

Robert:

If I apply your substitution then I get

“The design of the Ruby language already includes the basic closure as a
reason to use a module:”

This is the wrong substitution.

If I need a closure then I use a block but not necessarily a module.
Reasons to use modules are different (reusing a set of methods in
multiple contexts, including classes and instances, tagging a class with
a type tag).

It is the other way round: if a module needs to close over some local
variables then I use a closure.

Our abstractions allow you to go either way in one step. They also
provide some other interesting features: code injectors, decorators,
strategies, and control over code presence.

No, I said “methods and blocks”. This is trying to ridicule my question
by exaggerating my statement.

I didn’t think that answering your question was trying to ridicule you.
You may be experiencing some transference there ;-p) But really,
ultimately, if you don’t like the software by all means you don’t have
to use it.

The correct github link would be, however:

GitHub - LouHenryAlvarez/jackbox: Modular Closures: Ruby Code Injectors

Thank you, kindly

[louarnold]

Who are you and why hasn’t anyone heard of you? What are your plans for
future developments? Will you make the source code open source?

Thanks,

Kike

[louarnold]

ANNOUNCING a new release of Jackbox.

In this release we have primarily relegated code in the examples name
space to a second plane. It is assumed that if you want to run those
examples you will know to enable them in the spec_helper, and that you
will have the debugger appropriate for version of Ruby present on your
machine as we have eliminated the dependencies.

We have also started a new set of examples on injectors that illustrate
some additional properties of injectors we have cataloged under the
description “a shimmer of orthogonality”. They are intended to do just
that, show some of the orthogonality available to injectors with respect
to the rest of the library.

We hope you find the code illustrative, and please continue to send your
comments and inquiries to the address on Github. We will do our best to
answer them as quickly and knowledgeably as we can. Remember that some
of this is uncharted territory and we are kind of making it up as we go.

Thanks so much for the people that have show interest, and kind regards
to all.

lha

[louarnold]

6. ANNOUNCING a New Release of Jackbox.

In this weeks release we have completed the trend towards integration
with the Ruby base, and have eliminated all external dependencies from
the main library. It is now all PURE Ruby, The only dependencies
remaining are now the ones needed for the command line utility.

We have also added some more examples, and clean up others, and once
again tried to improve the ReadMe file. We are letting everyone know
that from now on we will doing our updates biweekly instead of weekly.

We would also like to take this opportunity to announce we will be
conducting what we have termed a Jackbox Challenge in the coming month.
We hope it will be to everyone’s liking and interest. We will be
offering a $1000,00 prize for the winner. We are still working out the
contest rules, but hope to have them ready soon.

Thank you again to all the people who have shown their interest and
support, and we hope to see you soon on a website near you.

For more info: Jackbox by LouHenryAlvarez

Lou

[louarnold]

ANNOUNCING the All-New Jackbox Contest

This month we will be finalizing the contest rules for the Jackbox
Contest. The winner of this contest will be awarded a $1000 dollar
prize. Please be sure to keep checking back in.

You can now also check our blog at: http://blog.jackbox.us. Also coming
soon our All-New website.

Thanks so much for all the people who have show interest and support.

lha

[louarnold]

Ladies and Gentlemen we have the pleasure to announce Jackbox RC1.

With this release we have completed our integration into the Ruby base.
We have also concluded a number of enhancements and addressed a couple
of previously standing issues.

The specification for Injector behavior under inheritance is now
complete. The spec on Injector naming and tags is also done. With
this release we also complete the specification on Injector Versioning,
and the introspection API. We introduce the concept of Soft Tags, and a
new coding pattern we have termed Transformers Pattern. We also
introduce a new alias to the #injector function simply named #jack which
fits in line with the product name of Jackbox.

There is now a trace of the target hosted Injectors kept through an
Injector #history also aliased to #versions. Moreover there is a
sub-trace to only the soft-tagged versions through the #tags method.
This history also holds a pointer to every #precedent in the chain. The
basic method #with has been refined to evaluate definitions for a module
using #module_eval and has been improved in some other subtle aspects.
The display of jacks on the console was also improved to hopefully
provide a more compact and more legible form. With this release we
also introduced the concept of equality to Injectors. Finally, this
release starts the exploration on using Weak References for Injectors.
We’ll see how that goes.

For a more complete list of changes and enhancements, please refer to
the CHANGES.txt on the gem itself as well as to the rspec files and
README.

I would like to thank once again all the people who have shown their
support and interest, and wish everyone happy coding.

lha