[13:55:21 CST(-0600)] <yzen1> colinclark: would you care to review my requreStub pull request ?

[13:55:34 CST(-0600)] <colinclark> yzen1: Sure, yes!

[13:55:37 CST(-0600)] <colinclark> I'd love to

[13:57:24 CST(-0600)] <colinclark> RTFSC

[13:57:31 CST(-0600)] <Bosmon> colinclark - I mentioned that you had opinions on the behaviour of requireStub

[13:57:40 CST(-0600)] <Bosmon> Since you had used its faulty predecessor in anger : P

[13:57:44 CST(-0600)] <colinclark> lol

[13:57:48 CST(-0600)] <colinclark> yes, opinions might be a stretch

[13:57:54 CST(-0600)] <colinclark> but certainly confusions

[13:58:12 CST(-0600)] <colinclark> I think my issue ended up revolving around a strange block of code...

[13:58:14 CST(-0600)] <Bosmon> I think it would be more accurate to say you are "full of ideas" : P

[13:58:44 CST(-0600)] <colinclark> lol

[13:58:54 CST(-0600)] <colinclark> Yes, so what was it that I encountered?

[13:58:59 CST(-0600)] <colinclark> Ah, yes!

[13:59:09 CST(-0600)] <colinclark> yzen1: In Flocking, I use a code editor called Ace

[13:59:13 CST(-0600)] <colinclark> The one from the Cloud9 IDE

[13:59:26 CST(-0600)] <colinclark> like much "modern JavaScript," it is require()-enabled

[13:59:42 CST(-0600)] <colinclark> Bosmon: yzen1, Justin_o, michelled and I were briefly talking about this today in a meeting

[14:00:11 CST(-0600)] <colinclark> Anyway, increasingly we're seeing code that itself uses one of what I imagine is a set of require()-based code loaders in the browser

[14:00:42 CST(-0600)] <colinclark> In my particular case with Flocking, I had some issues where the requireStub was smashing Ace's own require library by hijacking their require function

[14:01:00 CST(-0600)] <colinclark> I found that with careful and awkward file order, I could generally avoid it

[14:01:29 CST(-0600)] <colinclark> but I found myself writing this sort of thing instead, as boilerplate in all my files that are intended to work seamlessly in both Node.js and the browser:

[14:01:33 CST(-0600)] <colinclark> var fluid = fluid || require("infusion"),

[14:01:43 CST(-0600)] <Bosmon> It's the NEW COLLINNISM!!!

[14:01:48 CST(-0600)] <Bosmon> The BOILERPLATE OF THE AGE!

[14:01:50 CST(-0600)] <colinclark> lol

[14:02:06 CST(-0600)] <colinclark> In fact, the specific boilerplate that current occupies the top of every Flocking file is this:

[14:02:08 CST(-0600)] <colinclark> var fluid = fluid || require("infusion"),

[14:02:08 CST(-0600)] <colinclark> flock = fluid.registerNamespace("flock");

[14:02:18 CST(-0600)] <Bosmon> I still remember the old one from 2007

[14:02:48 CST(-0600)] <colinclark> My sense, when I was talking to Bosmon about it a few weekends ago, and which I brought up in the meeting today, tangentially...

[14:03:00 CST(-0600)] <colinclark> is that we might ultimately find ourselves surveying the require libraries that people are using

[14:03:06 CST(-0600)] <colinclark> and see if any of them are at all useful

[14:03:15 CST(-0600)] <colinclark> I guess it's an incredibly under-explored territory

[14:03:25 CST(-0600)] <colinclark> which has all kinds of performance consequences

[14:03:31 CST(-0600)] <colinclark> developer ergonomic issues

[14:03:31 CST(-0600)] <colinclark> etc.

[14:03:52 CST(-0600)] <colinclark> Bosmon: Justin_o was rightfully complaining today that it's very difficult, given a "thing" to know what files it depends on

[14:04:09 CST(-0600)] <Bosmon> colinclark - what kinds of THINGs has he been surveying?

[14:04:14 CST(-0600)] <Bosmon> Or is he talking about Infusion things

[14:04:20 CST(-0600)] <colinclark> In other words, given the "desire for an Uploader," how do you know what JavaScript files should be linked in the document's head?

[14:04:31 CST(-0600)] <colinclark> My response, somewhat flippantly, was two-fold:

[14:04:43 CST(-0600)] <colinclark> 1. You only need one file in your head, ever, and it's called MyInfusion.js

[14:04:43 CST(-0600)] <Bosmon> "get working on the Builder already"? : P

[14:05:04 CST(-0600)] <colinclark> 2. You look in the component's dependency declaration json and include those files

[14:05:44 CST(-0600)] <colinclark> yzen1 and I were saying that, as much as I feel very ambivalent about Node's module system, it's awfully nice to just "require" a module, and expect that it will take care of sourcing it's own physical dependencies

[14:06:10 CST(-0600)] <colinclark> but in the browser, this becomes rather complex, since we want code to load performantly and, typically, early

[14:06:17 CST(-0600)] <colinclark> is "performantly" even a word?

[14:06:30 CST(-0600)] <colinclark> anyway, those are my "plenty of ideas" on this particular subject, currently

[14:06:37 CST(-0600)] <colinclark> any thoughts from anyone?

[14:07:00 CST(-0600)] <Bosmon> Those ideas all seem sound

[14:07:12 CST(-0600)] <Bosmon> And seem unlikely to result in the destruction of a lighthouse filled with intelligent slugs

[14:08:13 CST(-0600)] <colinclark> http://en.wikipedia.org/wiki/Horror_of_Fang_Rock

[14:09:06 CST(-0600)] <colinclark> Bosmon: Speaking of boilerplate in Flocking, with your latest testing framework changes committed, am I free to get rid of this hack?

[14:09:07 CST(-0600)] <colinclark> fluid.registerNamespace("fluid.jQueryStandalone");

[14:09:16 CST(-0600)] <Bosmon> colinclark - I think you are, yes

[14:09:22 CST(-0600)] <colinclark> cool, I will try it one evening

[14:11:09 CST(-0600)] <colinclark> yzen1: Okay, so you are basically expecting that there will be a JSON file sitting on the filesystem, parallel to the HTML page where requireStub is used, which contains a mapping of module names to global names?

[14:11:39 CST(-0600)] <colinclark> Are you concerned at all about enforcing a contract here, which requires this JSON file to be in such a specific location?

[14:11:55 CST(-0600)] <colinclark> I guess this raises the question I had upon initially trying to use requireStub.js

[14:12:10 CST(-0600)] <colinclark> which is, essentially, "Do we expect people to actually use requireStub.js?"

[14:12:11 CST(-0600)] <colinclark>

[14:12:45 CST(-0600)] <colinclark> Meaning, is it a "convenient test utility" or is it something that people might actually use in their application code?

[14:12:55 CST(-0600)] <colinclark> This, I think is the key question

[14:15:04 CST(-0600)] <yzen> colinclark: ya the intention was to lookup the file in the js test directory that's, according to our convention, is a sibling directory to the html folder. As far as its use goes, it is used only in browser tests at the moment.

[14:17:06 CST(-0600)] <colinclark> ok

[14:17:10 CST(-0600)] <colinclark> So, we're basically saying

[14:17:50 CST(-0600)] <colinclark> "Use the Colinist II boilerplate if you actually expect your code to work in both Node.js and the browser"

[14:18:13 CST(-0600)] <colinclark> "And use requireStub.js in cases where you have Node.js-oriented code where you want to run its unit tests in the browser?"

[14:18:17 CST(-0600)] <colinclark> Is that right?

[14:18:24 CST(-0600)] <colinclark> And is it good?

[14:18:36 CST(-0600)] <colinclark> (I don't, for the record, know the answer to this question)

[14:21:11 CST(-0600)] <colinclark> By the way, yzen, nice fancy, promise-y use of $.ajax()

[14:21:33 CST(-0600)] <colinclark> Back in my day, we used "success" and "error"

[14:22:13 CST(-0600)] <yzen> colinclark: no I wonder if the code you demonstrated might let us load modules without the new require stub version

[14:22:26 CST(-0600)] <colinclark> I suspect it might, yes

[14:22:26 CST(-0600)] <yzen> colinclark: unless i m forgetting what the problem was

[14:22:53 CST(-0600)] <colinclark> I THINK the original motivation of requireStub was simply to deal with the unqualified calls to require() when we're in the browser

[14:22:57 CST(-0600)] <colinclark> Bosmon: Sound about right?

[14:25:30 CST(-0600)] <yzen> colinclark: I think you are right '

[14:25:40 CST(-0600)] <colinclark> So I dunno...

[14:25:49 CST(-0600)] <colinclark> do we really even want requireStub.js?

[14:26:01 CST(-0600)] <colinclark> I'm trying to weigh its advantages

[14:26:08 CST(-0600)] <yzen> colinclark: i dont think so

[14:26:22 CST(-0600)] <colinclark> and, especially now that it asserts a very specific contract on the user, I suspect it's not a general-purpose enough solution

[14:26:35 CST(-0600)] <colinclark> at the cost of us asking people to write this boilerplate around their require calls

[14:26:43 CST(-0600)] <yzen> i ll test it all as I m udpating to latest infusion and jqunit in gpii and if all works fine ill close it

[14:28:07 CST(-0600)] <colinclark> ok

[14:28:17 CST(-0600)] <colinclark> a bizarre conclusion to the code review :S

[14:28:34 CST(-0600)] <colinclark> It looks good, otherwise

[14:28:56 CST(-0600)] <Bosmon> Was the conclusion to abolish requireStub entirely?

[14:31:01 CST(-0600)] <colinclark> Seems to be the case, unless we can think of some compelling advantages for it

[14:31:04 CST(-0600)] <colinclark> which I'm open to

[14:31:37 CST(-0600)] <Bosmon> I'm very excited by the COLLINISM vs CODE motif : P

[14:32:41 CST(-0600)] <colinclark> lol

[14:33:00 CST(-0600)] <colinclark> colinism took quite a blow with the introduction of fluid.registerNamespace()

[14:33:25 CST(-0600)] <colinclark> I had this sort of nostalgic feeling as I swept away countless lines of var foo = foo || {}; lines from Flocking

[14:33:28 CST(-0600)] <colinclark>

[14:34:20 CST(-0600)] <Bosmon> It's great you have almost immediately found a way to compensate for the nostalgia

[14:34:27 CST(-0600)] <colinclark> ha!

[14:34:35 CST(-0600)] <Bosmon> It will be as if you never lived in a NON-COLLINIST era : P

[14:35:24 CST(-0600)] <colinclark> We just had to move the Coliny a bit further south

[14:36:19 CST(-0600)] <Bosmon> Always vital, when faced with Epistemological Challenges

Browser not supported