Parsing Delimiters (theory)

[MadGypsy]

Oh man, I am so stupid. I have figured out why overwriting has given me so much trouble. It's because of the smallest oversight possible in my script which is actually leading to an error that is silent.

My method for parsing names was as follows

(ex string)

parent:
{
	child:
	{
	}
}

lets say we wanted to get the name "child". First my script looks for : then it works backwards to the first { ( or , and grabs the text inbetween. Now on the surface this looks fine, until you consider that parent has already been parsed and what is then being sent through is

child:{}

ya see the problem? There is no {,( or , before child. In a case like this the name doesn't need to be parsed (heavily) cause it is the first instance of anything in the string. I need to write a condition that accommodates for this. BUT I am tempted to rethink the way I parse names altogether.

I will say, I have invented some nutty projects that were all very complex but I think this takes the cake. In all of my other projects the data being manipulated was simple data or (at worst) a math problem handles all the complexity. In the case of this project I have to parse all of this crap out in my head just to figure out how to tell the computer to do it and even the smallest thing left unconsidered can have me chasing my tail for days trying to figure out where the kink in the chain is.

I was convinced for 2 days that I hadn't found the proper combo to do overwrites, when in reality the overwrite instantiated the "one" possibility that I had overlooked. I'm chasing a good pattern while some innocuous bullshit is breaking the system quietly.

So, there is a little lesson for newb (aspiring) programmers. The output panel is your best friend and until you have completely finished you should be outputting every step of the process. I was convinced my stuff was elite and I had suppressed my "solid" output to the output panel. If I wouldn't have done that, I would have realized 2 days ago that there was a condition where names weren't being parsed.

Now to go fix this shit, get overwriting working and move on to loading images straight into the main Object. I get those 3 things out the way and I should be ready to start pounding out some example apps. Ones that are far more complex and useful than overlapping gradient images.

EDIT: Merry Christmas to everyone. I'm already enjoying the present that my output panel has given me. This project was dead in the water til I could rectify my issue and now that I know what the issue is, I can finally move forward.

EDIT2: NOPE, there is definitely a parse problem but what I described is not it. As it turns out, my method already compensated for the lack of a preceeding delimiter, pretty awesomely too. I didn't even realize what I had fully done til now.

I start by finding : and then getting the entire string up to that. Then I search the string for every occurrence of { ( and , - each "find" gets pushed to an array. I then set the begin position to the last occurrence in the string of the last delimiter stored in the array. If there is no occurrence, that number will be -1. BUT in order to increment past the delimiter I add 1 to the begin position at the last second, making it 0 which is the beginning of the string.

So you see, some kind of way I accidentally prepared for no delimiter. Awesome. Unfortunately, that means that my problem is happening elsewhere. I have some clues though. It only happens when an array is the first instance of an object and it's not that the name doesn't get parsed, it is leaving a delimiter in the first and last index.

overwrite = (0xAA9900

is not gonna work. Why is that being left there ONLY when it is the first child of an object? It is being trimmed from : to , instead of to ,

That means for some reason my script is not adding : to the open delimiter (in the case of a name) but it is overwriting the delimiter with :

Hmmmmm - this is like juggling snakes

EDIT 3: This is absolutely gazonkers. I have output every step of everything and it is all perfect until that last compile of my overwrite object. It even perfectly parses the object and everything, no delimiter problems - until that last second and it is being replaced somehow. It doesn't make sense because it is adding delimiters that are already gone.

I was positive that this meant it's parent was pushing it into the .content instead of turning it into an Object. This would make sense for wrong delimiters to be there according to the last split, but I output the .content of every object upon the .content being added and my overwrite object is not there.

hmmm - ghost .content. Somewhere I am referring to 2 different .contents. Like an alternate dimension, that for whatever reason would normally be identical but in this case they do not match. That's bad. Time to break out the singleton pattern (that I thought I was already using).

fuck...lol.

[MadGypsy]

HAH! I got it!

It was even dumber than the first thing I thought it was. I fixed everything with one line of code.

xxo.content = "";

Me and this line seem to be having a recurring problem. This is the SECOND time in this thread that a strategically placed version of that line fixed everything. Fuck that line.

So, it wasn't so much that there was a ghost.content as there was a condition where everything looks good but stray content is still present. I wasn't outputting content where I didn't expect there to be any, so I wasn't getting the key piece of information.

Thank the Lord that this is fixed. Yes, it really is for real fixed. Everything properly jumped to life when I added that line. It was a happy moment. Now to go add overwrite ability which will absolutely work the way I envisioned it now. Of this I am positive. The data already agrees.

EDIT: I'd like to say real quick that I am glad all of this happened. It forced me to take an extensive and thorough trip through my script. I gained an even deeper understanding of what I wrote is really doing and in the process small things along the way got written a little better.

It also reaffirmed to me that the grand majority of my script (if not all of it) is really solid. I'm using more of a procedural programming style to get the "core" built but I'm looking forward to converting it all into classes and interfaces. The end result will be an entire xxon (generic object notation) interpreter package.

..a singleton being run through a state machine within a factory pattern - that's pretty much what this seems to be. Or maybe through a factory pattern within a state machine. Hmmmm...I'll figure it out.

[MadGypsy]

OK, well, I have successfully added overwrite support.



You may notice that the import file has %num values in it. These get overwritten by the corresponding overwrite array index. Now I have basically built a template system. It was a total pain in the ass and it took me the entire day.


Also, I would like to correct an earlier inaccurate statement. My parser does NOT perfectly parse out .map files. I said this cause I remembered map files being JSON. It is similar in many ways, but there is enough difference that it's not going to just plug right in. So, I lied and I'm very sorry.

edit: Mentally I am maybe half way through how to convert a map file to JSON though. There is a whole lot of consistency in a .map file that could be exploited with .replace().

since the template should no longer be a child of implement once it is overwritten, it is moved to the parent of implement and implement is destroyed. I also added a .names system. This captures all immediate descendent names, checks to see if it is already stored and if not, it stores itself.

I actually added that only because I saw somewhere that I could. However, I used the new reference ability heavily in making overwrites behave. I can also now turn any name into a same-name AND only do it if it appears more than once within the same parent.

I'm going to work on images now.

EDIT: scratch turn any name into a same name. I COULD do this and then you could (ex) have multiple x properties on an Object. That is not a desired effect.

[MadGypsy]

XXON Parser Benchmark_12282012

This post is going to serve as a bit of rambling. I intend to cover where I am and where I want to be (within reason). Maybe I should start with the history of this idea.

About 5 years ago I found myself inventing all of these crazy projects that revolved around injecting my own data into some other framework. The first project was my XON parser. XON stood for extended object notation and it was like the bastard child of JSON. I recently went back and looked at that project. I got a good laugh at whatever nutty wavelength I must have been on to create such a ridiculous "mark-up".

However silly my "mark-up" was, the bottom line is that my system worked. I was able to do quite a bit more than I have my current "engine" doing. Somewhere along the way though, the project fell apart and by the time I revisited it I had no patience to re-figure out how it all worked (I am a notorious non-commenter. Well, I was. I have since seen the light).

The next project got even crazier. I skipped readable content all together and stored everything in colored pixels. I actually successfully turned an image into an entire database. One 256x256 .png could hold 198,000 characters. I even made it possible to parse THE IMAGE for named data. It was very solid and reliable, it was also VERY slow. I expected as much. The goal wasn't speed. The goal was to store data as colors and successfully get it back, on command. I reached that goal(this is an example of the possibilities, not intended to be considered an actual app)

While I was making all of those nutty things - I had this vision of a highly dynamic display environment, deriving from the script/image. The script/image would contain all the values and switches necessary to run the entire app. So, in essence (although I didn't perceive this) I was setting out to create a browser and my own "html/css/javascript/php".

---

I took a couple years off and focused (almost) entirely on 3D - every aspect of 3D. Somewhere along the line I fell into the Quake universe and all of the 3D that that entails. In my travels, I started noticing something - lots and lots of stuff was almooooost JSON. Like .map files, DP .ent files, Radiant .ent files, shader scripts, etc.

I noticed there was something else that could easily be described in JSON. Matrix3D values. I even noticed that .map files, already are them (Matrix3D values (I am referring to the flash Matrix3D class)). This means that by writing a JSON parser and then writing (ex) a .map to JSON converter, followed by implementing the Matrix3D class, my visions of a highly dynamic display environment just became 3D. Not only did it become 3D but with the immediate intention being to get radiant .map files converted, displayed, optimized and saved anew.

Now, I say "with the immediate intention" and I mean "...upon adding Matrix/Vector capability to my engine." As it stands now, I am not prepared to jettison into 3D ability. I still have a ton of 2D stuff to get out of the way.
As it stands now, this is the entire feature list.

1) gets & parses text files into a fully qualified object with proper parent/child relationships and value typing.
2) supports (Array, Object, Number, String, Boolean, Image) types
3) import support
4) overwrite support
5) 1 possible display type ( I haven't really worked on this end much, yet. However, my 1 possible display type is a drawing object so it can actually look like, well, anything )

This is actually really damn far. This whole thing is like, what, 3 weeks old? By the time I get to 9) my engine will have mega powers. Tweened animations, Events (mouse/keyboard/progress/complete) and 2 more display types would get me to 9). I already know what the 2 display types will be. Video and Text. 10) and I'm at audio. It took me 3 weeks to get to 5) on the mega hard stuff. I could have Video and Text in an hour (or maybe even 5 minutes, I've been writing code a long ass time. I have code).

With Events and Tweens I may also be able to basically plug code in, with very little accommodations needing to be made. I need to review these classes to be positive, but regardless, large chunks of code are definitely there for the picking.

---

I'm pretty sure no one reads this thread, but if you just did...thanx

[Mindf!3ldzX]

I read it, or atleast skim it brah I have no idea what I am reading most of the time though HEH.

[MadGypsy]

I feel ya brah. I know parsing delimiters is not some interesting subject :p , nor is it easy to read about. This is kinda like my diary. However, I will make you one promise and keep it very soon. This thread will transform from "Parsing Delimiters" to "Look what I'm making with all my parsed delimiters". The delimiters are parsed brah. Now I can start playing with the Object they create.

Object = config.cfg <- in mega-simple terms.

EDIT: Ooops I forgot something in my story. I had built (much of) an xml "engine" right before this JSON version. There's 2 problems with xml.

1) it in no way even resembles the files I want to work with, so conversion would be an amazing pain in the ass.

2) flash already understands xml. Actually flash already understands JSON too. I didn't set out to use someone else's junk. I'm primarily using the JSON format, but it's not identical.

My goal is to start from the very language and build a skyscraper on top of it.

[MadGypsy]

I have been thinking about this statement I made "Object = config.cfg". I do not like the facts of that. That is not what I am setting out to do. There are already ways where this it isn't entirely true that, my Objects are nothing more than a config file, but there is enough truth to it that I have begun to rethink the way my Object is read. I'm not referring to the parse, the parse is fine. I want an Object and I have an Object, but the object is serving as more of a database of vars (currently).

Right now, at this point, is when I need to make a decision like this. The next classes I write will be based on the Object working a certain way. Changing things past that, means rewriting all of it (except the parse).

I need like an Object 2.0 - a new and progressive way that an Object can be utilized. I want to revolutionize some shit. Along my path (writing the parser) it was like some ideas and code were "given" to me. I even wrote stuff that I didn't even realize fully what it was doing and what it was "doing" was, already properly catching a possibility I didn't even think of (hah). I believe in me and I believe this could all be something.

---

So, that's the scoop. I want to create a more powerful Object. I have no freakin clue where to begin or what I am even talking about. Something keeps telling me that the secret lies in a rubix cube, somehow (weird). Another thing I'm seeing is a Jenga stack (with it's perpendicular layers). I can't yet decipher how either apply. Then again, maybe I'm nuts and I talk to myself, like I'm also someone else, too much..lol .

comments are welcome

[Efess]

I didn't read the entire thread, but it sounds like you're trying to just build a JavaScript engine... JSON (JavaScript Object Notation) is just a convenient way to serialize JavaScript objects into text for communication (or save to persistent storage)

Also, there are plenty of libraries out there that can parse JSON already- fast and efficiently, why re-invent the wheel?

Maybe you could explain a little better what the end goal is?

[MadGypsy]

No, definitely not building a javascript engine (although you can talk to javascript and back). JSON does stand for Javascript Object Notation but that title is entirely misleading. JSON structure is identical to xml (excluding syntax) so if anything it should just be called ON (object notation) - as all it does is describe objects and javascript doesn't have to play a part at all.

@ JSON parsers that parse efficiently - I have already implemented features that would break those parsers. Also, I have benchmarked against flash's built-in parser and mine is a lot faster. Like 3 times faster. I parsed 1000 objects in 1.6 seconds, flash parser was almost 5 seconds. There is no comparison, my parser will eat Adobes for lunch. So "why reinvent the wheel?" - cause I make faster wheels (lol). I could actually make my parser even faster but then it will start completing stuff too fast and the other part won't be ready. I know this, cause I actually had to fix this issue. I guess you can say that I can make it so fast that it will definitely get in an accident.

@better explain what my goal is - That information can be found in this thread.

[MadGypsy]

Maybe you could explain a little better what the end goal is?

Actually, I would like to address this differently. The official answer is: I am not entirely sure. I know what the "mid-product" goal is, but I feel like there is something else here. Like, I need to make one thing, in order to have an epiphany about another.

To answer another one of your questions differently.

Also, there are plenty of libraries out there that can parse JSON already- fast and efficiently, why re-invent the wheel?

I "need" to make this from the absolute ground up. Every possibility, combination, event, whatever, has to be something that I created and have absolute command over, from every single level.

Why? Hell if I know. That's just how it is. Every time I try to start from someone elses beginning, my travels lead me right back to me starting from the ground up. All I ever accomplish when I try to "skip ahead" is a greater education/understanding of what I'm gonna have to build from the ground up.

I know my way seems "nutty". I don't see it that way. Even radiant .map files are stored in much the same way that I am storing info. Who's to say that it wont eventually all be "recompiled" to bytes? Maybe that's the "epiphany" in the "end" - how to manage this from string objects (developer) to bytes (user).

I'm not putting any limitations on the project. If I figure out 4D (lol), it will be implemented, but regardless of what I create, I have to create ALL of it. This means, I'm not going to be using a physics library or a 3dflash library. I will be inventing those things.

I also understand that if I was truly "inventing" it, I wouldn't be using flash at all. This is currently a means to an end. Flash supplies the "popular" browser embeddable player that I need. This is not to say that I will absolutely never consider building my own. For now, I am writing stuff that I would have to write no matter what. Porting it to a different language later can be phase 99 of all this.

EDIT: One thing I will definitely be making soon, is an editor. Using notepad sucks and notepad++ isn't any better really. I have keywords and stuff in my script that I want hilighted. I also want the editor to fix mistakes on every press of enter. I want it to be technically impossible to write bad syntax. Closing delimiters added and properly tabbed immediately upon the creation of the open delimiter -stick the cursor between them too.

I have missed a comma or colon so many times and it sends me chasing my tail trying to figure out if it's my parser or the script. Once I make an editor, I will go back through my parser and figure out how to report accurate script errors. This way the editor will stop you from writing bad syntax and the parser will stop you from inserting wrong data - like a boolean where a string is expected.

The next step would be to add a "display" frame that gives you realtime results of your script. Then implement the overwrite feature to create a graphical interface that doesn't require script. You could just click and change properties which are then written to an .xxon file for you.

yeah....I have a lot of work to do.

[Syluxguy28O3]

nice work so far. im very interested to see how this pans out.

[MadGypsy]

Thanks, Sylux!

I'm putting the finishing touches on my debut app. I call it "Hello World". I'll be posting it either tonight or tomorrow. I also have some more ideas.

I want the user to be able to create same-names somehow. Since my same-name system is an array that holds all the same-name values, I was thinking about including syntax like this:

Parent:
{
    child[0]:
    {
        name:"Bill",
        age:2
    },
    child[1]:
    {
        name:"Chucky",
        age:6
    }
}

This is essentially what is already happening with same-names during a parse, but only same-names that I built in (display,tween,event,implement,etc). By allowing the "developer" to create same-names will probably turn out to be very useful.

This is also why I wrote my own parser... and why I "have" to do it from the ground up. You cant do this child[0]: in JSON. At least I don't think you can. I've never seen that. I could make it possible in XXON as an afterthought. square brackets currently have no meaning. Even though import[someDir/someFile.ext] uses square brackets. I don't actually search for the opening one. I search for "import[" (lol). So, square brackets are fair game. I like child[0]:value. That looks like it's doing something.

The best part of creating something from the ground up is you get to make all the rules.

child[0] it is.

Just a note: I fully understand that I could just put all the same names in an array, without making any convention

parent:
{
    child:
    ({
        name:"Bill",
        age:2
    },
    {
        name:"Chucky",
        age:6
    })
}

This way would definitely already work, and it is the "pretyped" end result of a same-name. So why make child[0] a thing? IDK. I can and I like it. This basically becomes a way to assign individual indexes of an array as well. Errr, or maybe that is all of what it is - a specific assignation. Yup, that's what it is - and I like it even more.

edit: I literally ramble post my way to answers and decisions. You get to witness the unbelievable genius, real-time, as it pours from my skull.

[MadGypsy]

Hello World



Well, just like I said (albeit a day late) I am posting my debut app "Hello World". As you may notice, unlike other languages where you can simply write (ex) ECHO "Hello World"; - in my language it is possible to write a ton of stuff (lol). However, you also get a lot more than just "Hello World" out of it. Like, drop shadows and custom backgrounds, etc. You could write substantially less than this to make "Hello World".

app:
{
    display:
    {
        type:"TextObject",
        text:"Hello World"
    }
}

would have done the trick.

I threw the implement in there for a few unrelated reasons.

1) I wanted the trace commands for an implement to appear so they could be part of the image
2) I wanted to illustrate how it is possible to nest an implement.
3) It serves as one more example of the overwrite feature working

On that note I realized something about the overwrite feature. It perfectly imports, overwrites and then reinstantiates itself up a parent, but what it doesn't do is allow for me to extend the script.

What if I had a xxon "class" that described a certain way that I wanted to display an image. The only thing being overwritten is the image url. Now, lets say that I had two of these images but one of them I wanted to fade out on mouseOver and the other I wanted to rotate on click. Well you could just add an event object to the overwrite class that is dynamic enough to accept these changes, but that to me doesn't seem versatile enough.

I want to be able to say "get this class, overwrite it and THEN add all of this". I intend to implement that feature at the same time I work on child[0]. Which will be over the next 2 days. I will also be working on an events class, extending my effects class and simpleShader class as well as adding the video display component.

By a week from Thursday, I want to have audio support and a fully working flv player app.

EDIT: My engine also understands the filters keyword (vs filter). Filters is just an array of filter objects. Of course this is used if you want to have more than one effect. Currently only DropShadow and Bevel are supported. I will be adding (gradient)glow, blur and advanced (color multiplication/division)...maybe more.

This "engine" doesn't shine for little simple stuff like "Hello World". When I have added the rest of the necessary features to finally make a real app, the engine will shine in how elements can be implemented and overwritten (even extended). This will result in far far less code to get things done. Write something once, implement it for everything that looks almost identical (buttons) and overwrite the minute changes (text/placement).

When I get to the level of a real app, this will all start to look more logical.

THE FUTURE: Oh man, I just had this idea where you could define a theme in a document wide overwrite. Actually I don't even need an overwrite. I can simply say "if theme exists, view color as a theme reference". Maybe even treat it like constants. How many colors are in most themes 5? 7? Maybe array indexes for the theme could represent constants like INNER_BORDER. Even better, user defined constants.

like:

themeArray:
(
    BACKGROUND:
    {
        color:0x000000
    },
    BORDER:
    {
        lineStyle:5,
        color:0xA30808
    }
)

Hah. It's the xxon version of css. Yup, totally gonna make that happen.

[MadGypsy]

More Ideas

I just had another idea. Using the PHP GD library it is possible to make dynamic images, "on the fly" and have the php return that image as an image (ie not as php). For instance I could make a page like image.php and when I navigate to that page my browser will think I am viewing an image (not a php page).

Anyway, I could plug my engine into that function pretty easily.The use for this would be when you want dynamic data injected into an image for display purposes. In other words using links and stuff would not work, but maybe you want to make an image with statistics on it.

This method would be ideal for that because you could make the php script return an image of database information overlaying an attractive static (unchanging) background. I had every intention of creating a connection to a database anyway, this simply adds the bonus of being able to display that info on an image.

This is not what I am working on at the moment though. I am an optimizer. I optimize to death. So, I am currently making sure that "every bearing is greased" before I move on to child[0] and extended implements.

I have also decided that standard comments are useless. Especially with all the recursion that my engine produces. So, I have replaced the grand majority of comments with trace statements (ECHO) that tell me a story of the entire compile. I feel this way is superior as I can use find/replace all to turn my traces off in a click or 2 and they become the comments that they replaced.

find all "trace" replace with "//trace" - and vice versa

I already have thousands of lines of code, so this "recommenting" is taking a while. I have commented the importance of about 750 lines so far. I have about double or more to go. Luckily I am not tracing every damn line. I'd say the average trace covers 3 lines. I also trace loops only upon conditions being met so I don't have 1000 lines of "still searching" in my output. So, there is a bit of an optimization there as well.

I think Imma put that on hold (right now) and go add child[0] functionality. I'm thinking it is going to be easy. Lets hope what I see in my head and what I actually have to do are the same thing.

EDIT: :/ grr - it's tripping up somewhere. I found what is not happening, but I can't figure out why.

EDIT: Imma do what I did last week and talk out the problem right here. In the post where I was adding overwrite support, I came across a huge mess that all boiled down to one stupid line (xxo.content = ""). Well, this time I know that isn't the problem cause I have isolated that the content does not exist. Unfortunately, in this case, I need it to exist. It isn't being removed by either of the lines that I put that removes content. I know this because those all happen AFTER the part I am having an issue with.

---

OK, I figured one part out and got the object a little further into the process. I rewrote a small part of recursion to make a decision to look deeper if some conditions are met and I have now refound xxo.content. The problem was that normally I process arrays like Array.content, but since I am assigning a specific index off the bat .content was now stored in Array[0].content. I wasn't looking for that. I looked and I found. But when I then pick back up the normal processes to assign the .content - no go. It even says it's there, but it isn't doing anything.

---

Oh wait, I'm starting to put this together. - Like I said, before, Array.content was being processed, this meant that the Array had no indexes, so when passed back through indexes were assigned according to the content. In this case I am feeding an array index in, it's getting typed as an array and the content vanishes cause now Array[0] = new Array. HAH! BAM! that's why I type it out. ILL BE BACK! (lol )

---

Oh, I am dumb! pssh {sigh}. The problem was not a freakin problem.

consider:

parent[0]:
({
    //values
})

Do you see the problem with that? I will tell you the problem. I just assigned Array index 0 to be an array with an object in it. I don't know why I was stuck on trying to "type" the array twice, but once I stopped doing that my code worked great. Psssh.

This, is what I needed:

parent[0]:
{
    //values
}

See, now parent[0] = an object. Now you can certainly nest as much stuff as you want, But my player was expecting information to be in an exact spot. I moved that information from that spot by further nesting it in an Array. That was my whole problem, that and the deeper search actually (parent[0].content). I'm going to go back to all of this right now and make sure that it's locked up tight. I have some garbage processes happening that don't actually do anything. I am going to eliminate those possible conditions and make sure that this really really works. I did one test lol.


----

It works, period. I am glad I implemented this feature. I was able to take an entire chunk (about 15 lines) of code out of the script and combine it's functionality with the new .content system. I actually expect a slight speed increase. Not because of the 15 lil lines, but because now I am referencing things in a faster way. Also, now all the referencing happens in one spot, which makes it all that much cleaner.

---

OK well, on to extending the imports. If I finish that expediently I will move on to an Events class (or maybe that theme thing).

---

Another Idea:

Currently the implement keyword expects 2 children. The object/array to overwrite and an array containing the overwrite values. It performs all overwriting and then moves the new overwritten object up a parent, followed by destroying the original implement object.

That's great! But it could be better if I checked to see how many children it has first (I actually already do this) and if it has more than 2 or if even one of the children is not of the type array or object, it follows a different process (which I don't already do). The new process would be to overwrite as "self", meaning that implement would actually become the desired object. It would then be followed by duplicating itself under the proper name within the same parent, followed by destroying the implement Object.

The only hitch here is: where is this name coming from? Currently the name is derived from the name of the overwritable object. In this case that is "implement". That isn't going to work. Currently the root keyword for everything is display, but to assume that the object is a display is fool-hearty. Because someone may be implementing an effects, events or tween overwrite within a display. I could simply make a keyword inside of implement that needs to be assigned and that will be the name, but what if you use the old way where the Object already has a name? Then there would be this dumb field duplicating information. I could say: If field does not exist - do it the old way, but then we essentially have the same thing working 2 different ways.

hmmmm, this is gonna take some thought. I guess it's not a big deal if you can't overwrite less than an entire object. Maybe this was a dumb idea or too involved for too little gain.

[MadGypsy]

I am going to rewrite the overwrite feature. I see now where I can do everything I wanted to do but with a lot less code and processes.

Here is the gist. Currently, I am:

calling an implement that expects 2 children (an overwritable object, and an array of overwrite values). To add extendibleness (lol) I then throw in the extends object which is to hold all of the stuff that gets appended to the overwritable object. From there everything gets moved up a parent. That is ridiculous. way too much bullshit.

current:

implement:
{
    import[someDir/someFile.xxon],  //the overwritable object
    overwrite:("Tom","Dick","Harry"), //the overwrite values
    extend:
    {
        //additional content
    }
}

My new method will be to eliminate implement and extend altogether, by simply looking for an overwrite object within the already properly named and positioned parent

display:
{
    import[someDir/someFile.xxon],
    overwrite:(//add some values),
    //more of any kind of content can go here and beyond
}

See, it's "everything" without all of this extra keyword and replacement bullshit. In this case the import file could contain whatever. It doesn't even have to be an object. It could be:

name:%0,
age:%1,
DOB:%2

Since all an import does is replace its call with the text of the external document AND my new overwrite method will have no restrictions to be met, the data doesn't even have to be fully encapsulated, it just needs to syntactically fit where it is being placed.

technically with this new method you could even do this:

display:
{
    import[someDir/display.xxon],
    overwrite:(displayOverwrite, displayOverwrite, eventsOverwrite, eventsOverwrite, eventsOverwrite),
    import[someDir/events.xxon],
}

the only "problem" with that is display would have %0, %1 tokens and events would have %2, &3, %4. Meaning that events class would always have to use the 3rd 4th and 5th overwrite array values. However, that is not necessarily a problem since you can assign them directly

display:
{
    import[someDir/events.xxon],
    overwrite[2]:"mouseOver",
    overwrite[3]:"fadeIn",
    overwrite[4]:"easeInAndOut"
}

note for the programming illiterate: Array indexes start as 0 (in most languages). So, [2][3][4] is the visible 3rd, 4th and 5th position. I'll even throw in an FYI on why.

If an array length is say 5, then the last index is 4. When looping through an array you need a condition to be met as to when to stop. This condition is first created with an itinerant (var i:int = 0) the i will increment upon every pass of the loop. So now the condition for the loop is: if i < array.length. Since the last index is exactly 1 less than the array length, i has the room to move the full spectrum. On the last pass i increments (i=array.length) and the loop is over.

That is why arrays start at 0. true story (actually I am not entirely positive that is the reason for 0 index, but it is a product of it). I believe one based languages use i<=array.length as their argument and of course start the count at 1.