[dan.lewis]

At some point, I want to un-class the objects, and reduce them all to Property[]'s. It's practically a full re-write of the program structure, but this will sharply reduce the program size and complexity.

I also wanted to be able to use Value much like std.boxer.Box. I might even use std.boxer.Box; depending on it's efficiency. If not, being able to assign D typed values directly to the struct by overriding opCall and opAssign.

I've eliminated the textgen, and I've been hoping to move all string literals to messages.d and text.d. With some work, the engine could probably even get to the point where it was internationalizeable with two files.

I've got the ActiveXObject version(Windows), and it can enumerate the members available through COM. Remaining work is to bind the get/put/call interfaces to the COM successfully. Right now I'm having trouble with fromVariant() and Value* Get(char[] s){}

I'd also like to set up Dglobal_init() and Dglobal_eval() as the primary functions you call, and get rid of alot of crap from script.d, program.d and testscript.d.

I suppose the Dglobal_parseInt() and Dglobal_parseFloat() should also be better integrated.
_________________
nop
nop ; problem solved

[dan.lewis]

ActiveXObject
~~~~~~~~~
So far today, I've managed to get Walnut's ActiveXObject getting booleans, functions and strings properly.

In fromVariant, I still need to get it properly coping with numbers and properties that are objects.

Cleaning
~~~~~~
I've cleaned up a the source a bit more today, getting rid of some graft, version(none), version(all)/else, Value.copy() [instead of =], and V_xxx types in favor of TYPE.xxx types.
_________________
nop
nop ; problem solved

[dan.lewis]

Tonight I'm working late and going dancing, but my next step will be to fix ActiveX getting number properties, and to generally make Put work.

Once that's done, I think we need to actually create Dfunction's or something to use the normal Dfunction Call() and toString() setup and such. Right now, I just have it recognizing a COM method, and returning an appropriate string for it.

That will flow rather well into figuring out how to recognize someone accessing a property that is another COM object. For example:

[dan.lewis]

Hi guys, I've started work on Walnut 2.0; currently versioned 1.9 in my local folders.

It's beautiful. I wrote it from scratch.

It has core.d, methods.d, text.d, main.d, and structure.d; later I'll introduce a lexer/parser but I'm working on the backend first.

Value has overloaded everything so it works like a Box but with JavaScript types and only being 16 bytes.
Every type can be passed in a Value.
Objects are a Value[char[]]
Arrays are a Value[].
NULL, UNDEFINED, TRUE, and FALSE are static const's, as are all the strings.
Value's can be functions, and you can:

[jcc7]

[dan.lewis]

heh. I'll release very soon (a day or three?) to you guys. I just want to flesh out enough of it to demonstrate the entire design.
_________________
nop
nop ; problem solved

[dan.lewis]

Hi guys.

I've released what I've done so far for version 1.9.

I'm going to get back to finishing ActiveX before I do any more work on this. Essentially I think what I've done is released 1.9 before 1.1; which is bad for version control.

If anyone wants to help, I know enough to not commit before updating, so you're welcome to. Currently I believe the remaining requirements for 1.1 are:

1) to get ActiveX working for the Get of numbers, and the Put of all primitives.
2) to get ActiveX working so we can use the Call method to call a COM method.
3) to, on demand, create a means of accessing sub-objects of COM objects, such as excel.Worksheets.Add()'s Worksheets.
4) to write a new linux makefile that works.

Once that's done, I'll be comfortable calling it Walnut version 1.1 and stepping up to the next version.

[dan.lewis]

Mostly just me interested in working on this so far, huh...

Well, I've got 1.9 much more fully framed, with much of the program structure being done, and function stubs in place. I'm going to continue working on the Global_init() function to get the entire API visible, and then flesh out the function stubs.

So far, main() only needs Global_init() and Global_eval() to run something. You can call Global_eval() multiple times as long as you pass it the same Global from Global_init() it will "execute in the same environment".

Much easier to bind to than even Lua. Much easier source to read than any scripting engine I've seen so far... even Io (http://iolanguage.com/)

We'll see how long it takes me to finish though.

[dan.lewis]

Okay, revision 44 corrected much of the prototype/constructor structural issues.



For Walnut 1.9/2.X, I intend to late bind Values to Objects, so I'm still a little confused as to how I'm supposed to implement constructors with properties. I think I'm supposed to apply them as Objects with a __value__ of &theFunction.

For most other native functions, I keep the Value primitive, and the runtime functions I intend to do much the same, only creating an object if it's used. I also fully intend not to Objectify (3.9).toFixed(0); but instead simply pass the Value. That's why I changed the first argument of the function signatures to use Values instead of Objects.

Did you know:
JScript has serious flaws in it's implementation in that it returns "0" for a non-existant value or false, and "-1" for true?

JScript and JavaScript also differ slightly in that *.prototype returns slightly different strings, both being "function prototype(){...". My understanding so far of the ECMAScript Spec is that prototype is a property. Don't quote me on that though.

- Dan

[dan.lewis]

So I've enhanced Value so it can be used as an Object or Function naturally, and without any observable oddities.

I still need to fully implement TYPE based switches in all the Value operator overloads.

Implementing opIndex, opIndexAssign, and opIn_r with type switches that search for the property in Global[TEXT_Number][TEXT_prototype] instead of this - according to type - will allow me to naturally use primitives and literals as if they were Objects without them being so.

This is also how I intend to implement ActiveXObjects; they have their own type, and thus opIndex, opIndexAssign and opCall on their slots can be handled differently than for other Object types by using the very same switches.

Implementing switches on all the operator overloads may prove to have additional branching overhead as the type can be made known after the first switch and then be rendered branchless in a perfect world. But how does one implement this, considering call overhead is worse and a raw goto doesn't goback; and duplication of code is likewise painful.