Open ezShroom opened 1 year ago
prs are welcomed
@TodePond can this be a transpiler or do we do it the old fashioned way around here
@TodePond can this be a transpiler or do we do it the old fashioned way around here
no transpilation, all run-time :)
@TodePond can this be a transpiler or do we do it the old fashioned way around here
no transpilation, all run-time :)
aargh but like a good chunk of this is almost possible in pure js but not fully, like the with
block thing
it is all possible with with
s and Proxy
. the main issue is that I don't think with
gets passed down into functions blocks inside it, so I'm thinking about removing the with
requirement, and just stick with Proxy
madness. You could go ahead with some of the proxy-only features if you want! (Like .d
for example)
@TodePond Actually, it seems with
was the right choice. Without it, the variable definitions would be very hard to implement
without with
you could do something like:
var.name = "Luke";;
@TodePond any assistance on this effort to make airspace a thing would be appreciated
@ezShroom Just added a PR - #3 - you might enjoy with all it's...interesting design decisions😉. Turns out almost everything is possible as is, and with not much code to boot. The only thing that doesn't work are using the debug/execute literals on JS literals (Except strings. Works on strings for unknown JavaScript-related reasons.)
[3, 2].x(add)
doesn't work, but
someArray = [3, 2]
someArray.x(add)
does. Go figure. I'll be investigating if there's any way to support this in the future, but given my IDE gets upset at the .
and not the x
or d
, this might be a hard JS limitation. "Some string".d
is fine though.
Awesome, will check it out!
I know for a fact that .d
is possible though because I've done it in https://github.com/TodePond/Habitat
If your IDE is misbehaving it can probably be resolved by doing some jsdocs, or in the worst case scenario, an eslint plugin (or equivalent).
Oh hell, I just uncommented the code and now it works fine. Must have had a different bug that was breaking it, and my IDE just...knew? I'll check in a fix to the examples to use it as specced in the README.
Edit:
1234.d
doesn't work at all for JS syntax reasons, and [1, 2, 3].d
is printing 'y' for some reason - I presume it's grabbing 'Array' from somewhere. [3, 2].x(add)
does work though. I'll check out Habitat and see if I can wrangle a fix for the array debug statement.
For numbers you have to do (1234).d
If you do that, you also need to make sure the previous line also has appropiate colons (Or add pre-colons to that line), otherwise it tries to execute the previous line. In addition, for Arrays, a similar thing occurs. I had a print statement on the prior line without colons or brackets.
print.x = "Array debug below:"
[1, 2, 3, 4].d
prints y
print.x = "Array debug below:";;
[1, 2, 3, 4].d
prints 1,2,3,4
.
I've since discovered that "abcdef"[1,2,3,4]
- which seems to be a 4D array index access(?) - prints e
and only e
, so that's another JavaScript-ism. In my example, the lack of colons or half-colons defaulted to indexing the prior line. Looks like colon auto-insertion isn't infallable in Airspace, and is probably recommended. Might be a good idea to make it standard practice.
@danm36 How does modifying the main primitive prototypes for .d and such compare to implementing it on a getter (like in the very unfinished https://github.com/Shroom2020/airspace)?
Here it is in Habitat: https://github.com/TodePond/Habitat/blob/main/source/console.js
@ezShroom To be honest, I was just creating the examples in README.md one by one and when I got there, I figured "Hey, polluting the prototype is the easiest method!" Your method is definitely a lot cleaner when it comes to leaving an Airspace block. If I get time, I might ~steal~borrow your idea for my version and get rid of the global prototype pollution.
it no work