Skip to content

Instantly share code, notes, and snippets.

View genericallyloud's full-sized avatar

Russell Leggett genericallyloud

  • Abstraction Alchemist
View GitHub Profile
@genericallyloud
genericallyloud / codehike-proposal.md
Created March 30, 2016 20:32
CodeHike Brainstorming and Discussion (genericallyloud proposal)

Pitch

The demand for software developers is very high, and every year, there are more and more people who are abandoning or supplementing a mainstream college Computer Science education and utilizing coding bootcamps, online tutorials, meetup groups, and other means of non-standard or self-taught education. There are many, many, resources out there, some of which are intended to be a complete package, but most of which are not. Even the ones which claim to be complete, are only complete for some narrow definition. There are many different starting places, and many different destinations. No single solution has it all. Even resource guides which point to external resources can't cover the widest range of users without community driven content.

CodeHike is an attempt at providing trails and guides through the wilderness that is alternative coding education. More than just a list, or a list of lists, CodeHike would allow for trail blazers to provide hand crafted trails and guides through a series of steps th

@genericallyloud
genericallyloud / dispatch.md
Last active December 26, 2015 09:19
This is a bit of smaller scope functionality which could be used to implement Protocols and probably some other interesting patterns.

The idea for this is based on Brendan Eichs defineOperator function proposed for value objects, as well as trying to come up with a very narrow scope that can be used to build on top of, but also be possible to optimize. The basic concept is to define functions which can be used for single dispatch based on knowing the type of the receiver. It is the heart of what would be needed for protocols, but with an extremely narrow scope.

let foo = Function.createDispatcher();
Function.defineDispatch(foo,Array,function(){ return this.join(".foo ")); });

[1,2,3]::foo(); //1.foo 2.foo 3.foo
{}::foo(); //ERROR - no match, no default
{foo(){ console.log("Object foo");}}::foo(); //ERROR - doesn't support fall through

//here I pass the default function in

@genericallyloud
genericallyloud / protocol-definition.md
Created October 23, 2013 21:36
An updated protocol proposal simplifying the dispatch algorithm, and changing the Protocol constructor for more configuration.

So the idea for this updated Protocol definition is that instead of a string for each method on the protocol, the constructor takes

const Collections = new Protocol({ //if the value of the protocol method is NO_DEFAULT, that means it will not fall through, and since //there is not default, it must be implemented for the type, and will error if called for unknown types each:Protocol.NO_DEFAULT,

  //if the protocol method is FALL_THROUGH, that means that there is no default, but if the method is called on an
  //unknown type, it will try falling back to the object

map:Protocol.FALL_THROUGH,

@genericallyloud
genericallyloud / protocols.md
Created October 21, 2013 16:03
A potential solution for doing scoped binding of methods to types using a technique similar to Clojure protocols instead of Ruby refinements.

The following example uses the '::' operator which has a proposal already and a champion on the committee. Other than the bind operator, the example I give uses no new syntax (other than what is new to ES6), and could fairly easily be polyfilled - though I expect it could be optimized if implemented natively. If you haven't seen Clojure protocols, they allow for single dispatch polymorpism based on type, without the methods being defined as part of that type. In clojure, they use the first parameter, but for my proposal, it uses the receiver (this), and uses the bind operator to make the call look similar to a normal method call. While I haven't actually written an implementation of the Protocol class I demonstrate here, I've thought enough about it that I feel it could be done in a few different ways without too much complexity.

/**
  • The following module is a sampling of underscore methods conver
@genericallyloud
genericallyloud / PrettyUrlS3Client.java
Last active December 15, 2015 07:09
A drop in replacement (mostly) for AmazonS3Client, with the only modification being how keys are escaped in the presigned urls. The keys are still url escaped, but the slashes are left intact so that they can be part of the url in the browser.
import com.amazonaws.AmazonWebServiceRequest;
import com.amazonaws.HttpMethod;
import com.amazonaws.Request;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.handlers.RequestHandler;
import com.amazonaws.services.s3.AmazonS3Client;
import com.amazonaws.services.s3.Headers;
import com.amazonaws.services.s3.internal.S3QueryStringSigner;
import com.amazonaws.services.s3.internal.ServiceUtils;
@genericallyloud
genericallyloud / bind-operator.md
Created April 9, 2012 18:04
Proposal for bind operator

Proposal for bind operator

This is closely related to the @ operator that could be used as a shorthand for "this" in class methods, like in CoffeeScript. My proposal does not depend on it, but I think it would work nicely with it. It is intended to cover binding issues in both the short function syntax proposal, as well as the majority use case of <function>.bind as used today.

Examples

//let say I have some object foo with a method bar that I want called as a callback
//right now I have to use bind, or wrap the call in an additional function
needsCallback(foo.bar.bind(foo);

//also happens inside the class itself, and you'll see

@genericallyloud
genericallyloud / gist:2056771
Created March 17, 2012 08:45
Attempting to break <| between instancing and extending

There's something that's been nagging me about the <| operator ever since I first saw it. With the recent discussion (yet again) of a possible alternative syntax, I've been thinking a lot about it, and I think I've finally figured out what really bugs me (beyond the syntax itself).

The <| operator was born out of a few different use cases coming together (as listed in the proposal):

  • Specifying an explicit [[Prototype]] for object literals
  • Specifying an explicit [[Prototype]] for array literals
  • “Subclassing” arrays
  • Setting the prototype of a function to something other than Function.prototype
  • Implementing class-like parallel constructor and instance prototype inheritance chains.
  • Setting the prototype of RegExp and other built-in objects.
@genericallyloud
genericallyloud / unified-theory-of-everything.js
Created November 1, 2011 21:48
Unified class, <|, super, mixins proposal
// My take on unifying 3 concepts we currently have on the table:
// minimalist classes, triangle operator, and traits. This is mostly
// a rehash of existing ideas, with my own twist. Also - I will say upfront
// that the traits I'm proposing are for much simpler style ruby mixins
// because the traits proposal now are off the table.
// To start with, I'd like to advocate the minimalist approach that
// Jeremy Ashkenas proposed - the key element being (to me) being that
// it can take any expression for its definition. This is causing some
// debate right now, but I'll put that on the stack at the moment
// Here is a proposal for minimalist JavaScript classes, humbly offered.
// There are (at least) two different directions in which classes can be steered.
// If we go for a wholly new semantics and implementation, then fancier classical
// inheritance can be supported with parallel prototype chains for true inheritance
// of properties at both the class and instance level.
// If however, we keep current JavaScript prototype semantics, and add a form that
// can desugar to ES3, things must necessarily stay simpler. This is the direction
// I'm assuming here.