Skip to content

Instantly share code, notes, and snippets.

@pingjiang
pingjiang / call_cocoa_in_cpp
Created August 15, 2014 09:06
This program shows how to access Cocoa GUI from pure C/C++ and build a truly functional GUI application (although very simple).
/*
* test1.cpp
* This program shows how to access Cocoa GUI from pure C/C++
* and build a truly functional GUI application (although very simple).
*
* Compile using:
* g++ -framework Cocoa -o test1 test1.cpp
*
* that will output 'test1' binary.
*/
// Why do we need variance
// Invariant class List, just like in Java
class List<T> { /* normal list */ }
fun printContents(list: List<Any>) {
for (item in list) {
println(item)
}
}
@rwaldron
rwaldron / response.md
Last active December 15, 2015 14:28
This is in response to Peter van der Zee's blog post, http://qfox.nl/weblog/282

Peter van der Zee published this post on his personal blog and it was featured in this week's edition of JavaScript Weekly. The following sections each contain a piece of code copied directly from his post, followed by an irrefutable explanation of why it is either wrong or misleading.

EDIT, April 1, 2013: I've removed any harsh language, but the content and corrections remain the same.

These are facts.

Computed properties...

#include <memory>
#include <iostream>
#include <utility>
#include <algorithm>
#include <iterator>
struct sequence_tag {};
struct pointer_tag {};
anonymous
anonymous / gist:1406238
Created November 29, 2011 20:09
Originally:
https://gist.github.com/7565976a89d5da1511ce
Hi Donald (and Martin),
Thanks for pinging me; it's nice to know Typesafe is keeping tabs on this, and I
appreciate the tone. This is a Yegge-long response, but given that you and
Martin are the two people best-situated to do anything about this, I'd rather
err on the side of giving you too much to think about. I realize I'm being very
critical of something in which you've invested a great deal (both financially
@rauschma
rauschma / class.js
Created November 3, 2011 15:52
A minimal class proposal for ECMAScript.next
// Roughly: a combination of Jeremy’s and Allen’s ideas, updated with the results of recent discussions
// Guidelines:
// - Don’t use the same syntax as for object literals, but stay close.
// - Rationale: Some object literal features are forbidden in class declarations => don’t confuse people
// - Rationale: Comma separation is a bit tricky.
// - Keep new features at a minimum
// - Don’t obscure the fact that private names are actually name objects.
// => They can also be imported from somewhere else – a use case that needs to be supported.
// - In order to minimize confusion, keep module syntax and class declaration syntax similar.