Kris Zyp kriszyp

💭

Working on @HarperDB

SVP of Engineering @HarperDB

kriszyp / The built another.js

Created March 10, 2011 21:22

	(function(){
	var bar = (function(){ // each module factory executed, export assigned to var
	return {a:3};
	})();

	var text = {};
	text._resource = "contents of file";

	var pckg = {};// nested paths -> nested namespace/sub-objects
	pckg.foo = (function(bar){

kriszyp / my-widget.js

Created June 24, 2011 05:26

This is how I want to write structured documentation and unit tests

kriszyp / tap.js

Created July 27, 2011 22:32

	define(["./base/lang"], function(lang){
	// module:
	// dojo/gesture/tap
	// summary:
	// This module provides tap gesture event handlers
	// - dojo.gesture.tap -> to fire 'tap' event
	// - dojo.gesture.tap.hold -> to fire 'tap.hold' event
	// - dojo.gesture.tap.doubletap -> to fire 'tap.doubletap' event
	// example:
	// A. Used with dojo.connect()

kriszyp / output.txt

Created October 6, 2011 17:17 — forked from iaincarsberg/output.txt

RequireJS - Compose.js - Chaining Multiple Constructors

	Animal - this {}
	Animal - debug: [ muppet , bert ]
	Hello, my name is bert and I am a muppet
	returned: { species: 'muppet', name: 'bert' }
	****************************************
	Muppet - this {}
	Muppet - debug: [ ernie ]
	Animal - this {}
	Animal - debug: [ muppet , ernie ]
	Hello, my name is ernie and I am a muppet

kriszyp / gist:1690583

Created January 27, 2012 19:50

	# My Cool Package

	Here is little introduction.

	## module-a

	A little intro to this module. here are the methods/props:

	<pull-in-from-api-docs> <!-- get stuff from code -->
	<example for="myMethod1">

kriszyp / dual-boot.html

Created April 9, 2013 14:34

	<!DOCTYPE HTML>
	<html>
	<head>
	<title>Dual Boot Test</title>
	<style type="text/css">
	</style>

	<script type="text/javascript" src="/dev/dojo-release-1.3.3-src/dojo/dojo.js"></script>
	<script>
	console.log("dojo 1.3", dojo);

kriszyp / gist:5464150

Created April 25, 2013 23:50

kriszyp / gist:7439619

Created November 12, 2013 22:05

Whether or not to auto-own() widget aspects

	Dylan was asking me about the own()'ing of aspects, so I thought I would try to write out the issues in case it would help. The issue associated with not own()ing the function (https://github.com/dojo/dijit/blob/1.9.1/_WidgetBase.js#L940), is that if a reference to the widget or the handle is retained after destruction, the function is still referenced just as it was when it was live. What has made this a debatable issue though, is that if a widget is referenced after it is destroyed, is that really a valid use case? Is leaving such a reference itself a memory leak, and should be fixed, rather than trying to make memory leaks be smaller leaks? The downside of own()ing all aspect handles is that own()ing has a cost itself, each owned reference takes up a slot in an array, so by own()ing aspects, we are effectively punishing the vast majority of widgets do not ever end up with a reference to a destroyed widget.
	It might help to look at a few different scenarios:
	A single widget: when a widget listens/aspects t

kriszyp / gist:8446857

Created January 15, 2014 23:29

	> foo = new Model();
	> foo.bar = {baz:3}
	> foo.property('bar').property('baz').observe(function(value){console.log('baz new value', value);});
	> foo.set('bar', {baz:5});
	baz new value 5 VM6359:2

kriszyp / gist:cdd6fa337eebb3d8ba55

Last active August 29, 2015 14:20

	import { mixin, declareFrom, after } from 'core/traits' or 'core/compose'

	class Request {
	get() { }
	}
	class Cache {
	@after /* add something to the method so that mixin knows that it should run after the method it is overriding? */
	get() {
	}
	invalidate() { }

	/* This is the module, the implementation, distinct from the specification/interface. */
	define([...deps...], function(){
	return function(options){
	...
	};
	});