Removing the necessity to use b.

[ff6347]

get rid of the b. to make it more Processing like and even easier to write

[ff6347]

This might help
https://github.com/sindresorhus/bind-methods/blob/master/readme.md

[b-g]

Thanks! But I think we don't need any magic external stuff for this ... this seems pretty easy to write on your own ... and if external, then something more generic eg. underscore extend.

[ff6347]

I think we do need some magic. I've been trying several ways to add the functions of an object into another functions scope in extendscript but it dies not work. I of course tried the method you suggested without luck.

Had a look into the bind-methods source. es6 to es5 transpilation does not solve the problem. Maybe the underscore extend is the way to go.

[ff6347]

tried lodash.assign as well. No luck. If anyone as a suggestion how this could work without adding all of Basils functions to the global scope - please enlighten me 😞

[b-g]

So something like https://gist.github.com/medikoo/2394476 does not work in extend script?

And if your write simply at https://github.com/basiljs/basil.js/blob/master/includes/core.js#L34 eg.

glob.fill = pub.fill

Is fill then global?

[b-g]

or in https://github.com/basiljs/basil.js/blob/master/includes/core.js#L46 just for the scope in setup

glob.setup.fill = pup.fill

[ff6347]

nope. I tried several solutions. Created a small version of Basil for testing purpose https://github.com/fabiantheblind/micro-basil

[b-g]

Odd, we is then this line working? https://github.com/basiljs/basil.js/blob/master/includes/core.js#L3

IMO this should work ... might have time to look into it end of the week. Sorry! No more ideas on my end.

[ff6347]

Played a bit with it.
line 3 in core adds pub as b to the global scope. When adding glob.foo = pub.foo like this. It works fine. Adding pub.foo to the scope of glob.setup does not work.

I need to finish a project as well. Then there is some time for Basil.js 2

[ff6347]

glob.fill = pub.fill
Is fill then global?

yes it is.

[b-g]

Had a look this morning. The underscore bind functions works for me. I'm able to "inject" variables e.g. var name into the scope of the draw function. But unfortunately I can't get rid of the **this.**name. Hmm ... ideas?

#includepath "~/Documents/;%USERPROFILE%Documents";
#include "basiljs/bundle/basil.js";

// underscore 1.4.4
#include "basiljs/libraries/underscore.js";

function draw() {
  b.println("hello");

  b.println(this.name); // works

  // how to get this working?
  b.println(name); // error!
}

this.draw = _.bind(this.draw, {name: 'moe'});

b.go();

[ff6347]

There might be some solutions in this SO thread I started.
Using eval and nasty things like that.

http://stackoverflow.com/questions/38147118/add-function-into-the-scope-of-another-function-javascript

[ff6347]

Hi guys, I've been thinking a lot about this issue in the last week or so. While preparing my upcoming seminar it becomes more and more obvious to me that we need to remove the b.. It seems like there is no way to just add the functions of basil to the scope of setup and draw without doing some regex/eval magic on the functions.

Can somebody explain to me why the functions of Basil should not be in the global scope?
In Processing and in P5.js all the functions are in global scope. It is normal to not create own functions called random or draw and everything worked fine for the last 15 years. So my suggestion is: Let's move everything into the global scope. I gave it already a test run and there seems to be no difference in the execution time.

[ff6347]

I tried to compare the execution time of the same code in the current version and a version where all functions of b are also added to the global scope (for backwards compatibility). As you can see there is no actual difference in the execution time.

with Basil.js 1.0.10

// @includepath "~/Documents/;%USERPROFILE%Documents";
// @include "basiljs/bundle/basil.js";
    function setup () {
      doc = b.doc();
      b.clear(doc);
      for(var i = 0; i < 500;i++){
        b.ellipse(0,0,10,10);
      }
    }

    function draw() {

    }
    b.go();

// with 500 ellipses
// [Finished in 13.4s] without open document
// [Finished in 17.0s]
// [Finished in 17.8s]
// [Finished in 17.2s]

with Basil.js 2.0.0

// @includepath "~/Documents/;%USERPROFILE%Documents";
// @include "basiljs/basil.js.dev/basil.js";
    function setup () {
      doc = doc();
      clear(doc);
      for(var i = 0; i < 500;i++){
        ellipse(0,0,10,10);
      }
    }

    function draw() {

    }
    b.go();

// with 500 ellipses
// [Finished in 13.4s] without open document 
// [Finished in 17.5s]
// [Finished in 16.9s]
// [Finished in 17.6s]

[trych]

Just to keep things moving: As long as b. still works and it does not make anything slower, I would say, sure why not?

What do others say? @b-g ? @ffd8 ?

[ffd8]

My two cents,

• it needs to work without including any external library.. otherwise it complicates goal for simplicity and demographics.
• the b. can still be useful for explicitly saying 'this is a basil.js code'
• the b. is annoying when porting scripts from Processing.. but int/float/String-> all still have to become var... If the focus is on porting from Processing, then maybe there could be a pre-parser function to catch all of those functions/vars and tweaks them on the fly.. that might also be incredible dumb and tricky. Perhaps best as an online website tool for paste + copy code tweaking?
• to my understanding the reason to avoid global scope is future compatibility.. not running into any conflicting new functions that come from Adobe.

I'm still for the removal of b. – but want to make sure it's only done when keeping things easy and beginner-proof.

Side note.. your example above is still converting the #includes to @includes... is that really necessary? it would cause the break of all code written before. ** same is true for removing the b., it's of course ideal if done in a backward-compatible way, so b.function() still works...

[b-g]

Hi all,

I hereby try to summarise the discussion ... so that we finally can get that off the table:

• expose b.something to global scope is fine e.g. b.fill becomes fill. (Please research how p5.js is dealing with it)
• global style does not prevent users to use old style b.something for backward compatibility reasons
• global style has to work without introducing new dependencies e.g. no external library
• #includes of examples will be untouched and will still be working
• @includes will be used for everything in /src/*

I furthermore suggest:

• start using the development branch for this (we don't want that public before heavy testing)
• @fabianmoronzirfas and @trych use the new global style in their teaching appointments, so that we have real feedback until the end of the year. If the feedback is good, we release basil 2.0 "global style"

Please go ahead!

[trych]

Sounds good, just two remarks:

#includes of examples will be untouched and will still be working

I see no reason to not change them all to @includes eventually. There is absolutely no hurry for that, but in this issue I propose to improve the example scripts anyway and I think if we are touching them all anyways, we might as well just switch to @includes. Or is there any reason not to, that I am missing?

@fabianmoronzirfas and @trych use the new global style in their teaching appointments

I can definitely mention that it works without b. now, however, as long as all the documentation and examples still use b. I would still prefer to also teach the b. way. I do not think in my course it's gonna be such a problem, as I am not teaching Processing or p5.js on the side (unlike Fabian, I think). So, I will mention it, but still mainly go with b.. Hope that's ok.

Does this mean we release a basil 1.0.11 soon before the semester begins (by Sept 19th in my case) with the global style and with the bug fixes and features we have so far? I think that should be the way to go.

[ff6347]

as I am not teaching Processing or p5.js on the side (unlike Fabian, I think).

Yes thats right.

Does this mean we release a basil 1.0.11 soon before the semester begins (by Sept 19th in my case) with the global style and with the bug fixes and features we have so far? I think that should be the way to go.

That or we create a prerelease for the global style. The bug fixes and new features should go into master. The global style is not ready for master yet.

[b-g]

OK to @includes in examples as long #includes are working too.

OK to release the new mode as soon as possible. But this release should be clearly an alpha (unstable, not for production) of the upcoming 2.0. Hence it might be good not to communicate this on the official website.

You can of course also teach the b. way :)

[ff6347]

Okay guys. This commit 993c255 allows to call all functions without using b.

I'm trying to wrap my head around a way to get rid of the b.go() as well but I can't come up with a solution. If we wouldn't have the different modes we could just call the b.go ourselves but with the different modes there seems to be no way to do that.

So my suggestion is. Including this into the core but keep the 2.0 version backwards compatible by keeping b.go() at the end. For a 3.0 version we could reevaluate how the whole calling of basil could be done. I could think of having the modes and and the loop function as global flags in the start of the script that get checked instead of having them as function calls and parameters.

One thing to, if you teach the usage of basil without b, is that something like:

var doc = doc();

won't work anymore. This of course overwrites the function doc. So variable and function names the user declares can not be the ones used by Basil.

[ff6347]

I would love to hear from you about this before I create a PR.

[ff6347]

All test passing.

Indesign returned: 53 test cases run
239 assertions run
239 passed
0 failed

[b-g]

Hi @fabianmoronzirfas! Yay!! 🎉 I feel so Processing like now! :) A few comments and questions:

1. did the performance change (polluting the global namespace) in comparison to the b.something approach?
2. at the moment the code below confusingly works. I would suggest to check before injecting each basil api command to the global scope whether there is already a var defined with the same variable name ... if so, throw and error, give a hint what is wrong and stop executing the script

#includepath "~/Documents/;%USERPROFILE%Documents";
#include "basiljs/bundle/basil.js";

var fill = "nonsense";
var rect = "nonsense";
var color = "nonsense";
var random = "nonsense";

function draw() {
  var newRandomColor = color(random(0,255));
  fill( newRandomColor );
  rect(0,0,b.width,b.height);
}

b.go();

1. I would favour instead of b.go(); just go()
2. Cool that anything prefixed with b. still works!

[ff6347]

1. The performance did not change. I'm also buffeld :-)
2. Yeah you are right. The check is a good idea. I'll take a look into it these days.
3. b.go/go I would love to get rid of it for good but it's not possible right now. Maybe the go() will do it.
4. Yeah having it backwards compatible is great. Means no need for a full reference/tutorials/examples change.

[trych]

One thing to, if you teach the usage of basil without b, is that something like:
var doc = doc();
won't work anymore.

Does that mean also var doc = b.doc(); would not work anymore? Because, if so, I think this would indeed break backwards compatibility for quite a lot of scripts.

[ff6347]

var doc = b.doc();

still works. It's just the overwriting of global variables. It is backwards compatible.

[trych]

Cool! Looking forward to this then. Had the first student today who was very fascinated that you can just take the b. out of your script and then use it in Processing pretty much straight away. He will be happy to hear that he does not need the b. in the first place from now on. 😎

[ff6347]

Yes. I'm totally into it as well. I'll be OOO for the next few days. I hope I find some time in Quito to hack on Basil. If not I will continue on this after the 24th

[trych]

b. has been removed. :) Closing.