deanveloper

(function( $ ) {
    $.fn.simulateDragDrop = function(options) {
        return this.each(function() {
            new $.simulateDragDrop(this, options);
        });
    };
    $.simulateDragDrop = function(elem, options) {
        this.options = options;
        this.simulateEvent(elem, options);

deanveloper

[Event "Rated Blitz game"]
[Site "https://lichess.org/16Eq8ybO"]
[Date "2020.03.01"]
[Round "-"]
[White "deanveloper"]
[Black "Azizlumiere"]
[Result "1-0"]
[UTCDate "2020.03.01"]
[UTCTime "19:00:00"]
[WhiteElo "995"]

deanveloper

package main

import (
	"fmt"
	"sync"
	"math/rand"
	"time"
)

func main() {

deanveloper

My previous proposal was pretty well received, but @networkimprov had mentioned that I'm solving three separate problems at once, rather than addressing them separately. I think that's an important thing to consider, so hopefully this new proposal addresses this. This proposal is largely inspired by my previous proposal, so I very highly recommend reading that on to see the design philosophy. golang/go#28987

That proposal also goes over how other languages handle enums, and how we can learn from them.

Problem

The problem with non-namespaced variables is largely illustrated in my previous proposal, but to summarize, if my mat package has a Material enum and a Hardness enum in my package, I would want these things to be separated into mat.Material.Metal and mat.Hardness.Hard values, rather than just mat.Hard and mat.Metal being in the same namespace.

Solution

deanveloper

Unifying the ideas of Contracts and Interfaces - Contract Embedding

This proposal is largely based on my previous proposal, which can be found here. It had a few problems though, which are fixed by this proposal.

The draft's reason to not use interfaces

It is unclear how to represent operators using interface methods. We considered syntaxes like +(T, T) T, but that is confusing and repetitive. Also, a minor point, but ==(T, T) bool does not correspond to the == operator,

deanveloper

This proposal has been moved

---

It is unclear how to represent operators using interface methods. We considered syntaxes like +(T, T) T, but that is confusing and repetitive. Also, a minor point, but ==(T, T) bool does not correspond to the == operator, which returns an untyped boolean value, not bool. We also considered writing simply + or ==. That seems to work but unfortunately the semicolon insertion rules require writing a semicolon after each operator at the end of a line. Using contracts that look like

deanveloper

Go 2 Error Values

My main critique with Error Values is the Formatter interface.

I fear that nearly every format function will be written in the exact same fashion:

func (e *MyErr) Format(p errors.Printer) (next error) {
    p.Print(/* short error string */)
 if p.Detail() {

deanveloper

//
// Author: Dean Bassett
//
// Converts JSON to an HTML string. JSON is assumed to already be HTML-Escaped.
// The name for function is inspired by the C function `atoi`.
//
// this converter takes an object with 3 attributes:
//    tag (string, required):   the html tag
//    attributes (object):      key-value pairs which represent the attributes for the tag

deanveloper

Keybase proof

I hereby claim:

• I am Deanveloper on github.
• I am deanveloper (https://keybase.io/deanveloper) on keybase.
• I have a public key whose fingerprint is 2ECB 9779 A93D CE23 EA9E 5960 399C B2DA 279A 4C12

To claim this, I am signing this object:

deanveloper

>+[                       loop (add 1 so the loop executes; keep #0 = 0)
  ,                       take input
  [->+>+<<]               copy into next two cells
  >>                      go to 2nd copy
  [-<<+>>]                move value to original cell; makes "origin" & "copy"
  <----- -----            subtract 10 from copy

  note: copy's value is not relevant; all that matters is that if it is 0
  (aka if the char was a newline) that it will break out of the loop!
  this means that we can overwrite the copy with the next character; allowing