StarShine factory composition

It's become a habit of mine to discover and re-create my libraries with a twist using a slightly different technique. The flavor of this week is starshine.


It's easy to overlook a small library like this. Here are a few of it's features.

• StarShine() returns a factory. It's composed of the closures and objects that it gets passed.
• It has built in internal storage and private "shared" variables. (More on that later)
• Objects are defined by Javascript primitives:
  
  1. reusable closures
     
  2. properties
     
  3. methods
     
  4. prototypes
     
• Works like a function composer

Each function closure should encapsulate a piece of functionality like this: I cannot stress more that being able to share private variables between closures is a crazy fundamental tool that every developer should use. I have personally used something like this in my personal code: Each factory has it's own prototype, take the following example. There is no way to make a prototype chain using this method, or maybe there is and I'm lazy, but this seems to be the only way I know to get prototypical inheritance: If someone comes up with a better idea, I would love to modify my code to make it more flexible. Getting access to the prototype itself is useful with instanceof, but I highly doubt it is necessary. Chances are you probably just wanted to create a new prototype and set the _type property. Given the following example:
Accessing a simple property is probably going to be easier on your code and is simply faster.

This library is everything I love about javascript combined into one tiny little package, and I hope you like it.

SnowBlower and Object Composition

I'm going to talk about this "library" and why it's very useful. It takes a lot of the compositional techniques of objects and makes it really fun.

Here's an example of how to use SnowBlower.


It takes all the functions and objects that you pass to it, and either executes it in the context of your new object, or mixes it into your new object. If you need polyfills for your environment, just define Array.prototype.reduce, Object.create, and replace the Object.prototype.hasOwnProperty function to reflect your environment.

It's designed to be small and SnowBlower assumes you have all the pieces and closures that define your object up front. If you need to compose factories, you can just create a function that does it for you.


This is a DRY method of reusing functions you have already defined to compose objects. The sky is the limit! Just thought I would share this compositional technique with you.

~function(){console.log('josh')}();

Yet Another Gulp.js Post - Compositional Gulp

Gulp is the new build tool and I highly recommend that you use it over grunt for building things. I found that it's nice to do something like this (taken straight from the repo example):


I mean look at it, it's really clean, except for the anonymous callback pattern.

Yet maybe I'm missing something here. Take a look at the following snippet:


Take a minute and think about it. This enables you to make command line tools that do whatever you want!

Even better, what if you used a functional composition library like... say... Composer.js?


So this is really cool, and make your own judgements, but you can do some interesting things with it. For example, remember that this is the object that composer is making, right? See the following.


That was fun! Sure it may not be the best way to build your gulp tasks, but surely this allows for mix and match DRY task factories.

Are you going to use it? I'd say get back to writing fun code ;).

In functional health,
~function(){console.log(this)}.call("Josh");
"Josh"

P.S. Don't forget about Composer.symphony

Edit:


This example shows the sheer power of symphony which give you DRY tasks given a good configuration. Watch out though, because this is a Object.created version of gulp.

Classical Inheritance is dead and what you can do about it

There is nothing new in this blog post, but all of this is worth mentioning to everyone repeatedly. If javascript was meant to have classes, it would have had them in the first place. Instead we are stuck with the following clunky syntax and keywords to do type checking.



Instead you probably just wanted this.



Look at how simple that is! It's so much faster. Even to a beginner programmer, the hint that this.name may actually be the name property of the object literal.

Need to do instanceOf? Why not do something like this instead?



Seriously! There's so much less code. In fact, why not just  forget the whole "new" paradigm? Well, maybe not forget, but use it wisely. It also begs the question, how do you make objects repeatedly? Don't you need some kind of overhead? What about applying prototypes to already created objects? Or worse. What about multiple linear inheritance?

Your goal when making applications is get the banana. Not the gorilla, not the jungle, and not everything else. See the following video.

Perhaps it might be overstated that using stampit is quite useful. It is also very close at getting the banana. At 10kb I found that stampit was the correct solution on the back end where we control  the modules. Size doesn't matter on the back end. On the front end, it might be more like a fruit salad to a mobile phone. I also have nothing but respect for Eric's library, because it really showcases the fundamental units of object creation.

Could you perhaps have wanted something smaller? (Yeah it's a pretty shameless plug.)

After all, passing callbacks should be really terse.

We should always remember the few components that comprise our objects and functions: Properties, values, closures, functions, prototypes, and contexts.

Edit:
Don't forget to check out the npm registry for my library composer.js.