WorldSpawn official WIP thread

[MadGypsy]

This is all the final possibilities. It all works.

[MadGypsy]

@it seems like you're still tackling really low level problems

Well, "still" is not a good word and these problems are not directly engine related. The work I am doing here will change how I manage objects in haxe no matter what I am building. I got sick of how cumbersome it was to deal with objects and I just now decided to do something about it. I "just now" became good enough to even consider it.

@What would you say is your overall progress on the engine?

Around 80%. I'm not crying about the low level stuff because, my engine is damn near done. Well, at least in a "fully functional" sense (with some extras).

I have an idea of how to tie bytestream into the key. My idea basically would allow bytestreams to automatically be parsed to a key based on the default expressing the structure and what kind of bytes to read for each field. This means I should be able to put in a bytestream and a "template" and get back ex: a bsp fully parsed to an object. I should probably extend Key for this (ByteKey?).

Side Fact: Making all these changes does not break my code. Reflect still works on a Key because the underlying type of Key is Dynamic. This means if I miss a spot in my code somewhere while converting everything to the new way it isn't going to break anything or have any impact at all for that matter. All these changes I am making allow a new syntax but does not break the old syntax.

[MadGypsy]

added the ability to delete fields with a subtraction operator (lines 54 to 5

[MadGypsy]

I added 2 more features last night. Mostly, one begat the other. I said earlier that I could easily print the object as valid json so, I went ahead and did that. IntMap was already being printed as array and StringMap was already being printed as object so...

By running the built-in JSON parser on my JSON print I end up reformatting the int and string maps to actual arrays and objects. That is the second feature ~ reformat();

I also started working on BytesKey but I am a little more than nowhere on that one. I realized I cannot extend an abstract so I am going to utilize the Key abstract instead. Just writing the header for BytesKey I realized it is going to be substantially more involved than Key was. Key was like a starter-kit abstract. It got my toes wet on how to make an abstract. BytesKey is going to be the real challenge, especially with the dual purpose I want it to have. Initially, the point is to template the final object in such a way that it becomes directions on how to parse the bytes. After that I want an interface that is so smart I can write bytes without even describing them. I understand it in some barely reachable part of my brain. I need to get it to the "front"

[MadGypsy]

final


My Key abstract is superior to probably any other container type. No matter which supported type is inside of it, access of every type is unified to the possibilities in the above image. There is no consideration like - "This field in my Object is a Map type so, let's use Map code" or "This field is an array so, we have to get a reference to it and treat it like an array.". Everything is the same thing...even if it's not.

BUT

You still can "use map code" or "treat it like an array" or any other thing that is normally available. I just made the "SMC" for an Object. There's all these new features but not one original feature was lost. Unlike the SMC though, there is nothing to turn off/on and it's compatible on everything.

tadaa...

[MadGypsy]

I am actually not done with my Key. fields(), copy() and forEach() need to be upgraded to use keys. Those are the only 3 functions that will only regard the entire object. It's 2 minutes to 11. I'm gonna start at 11. I want to get a really good idea of how long this takes me.

[MadGypsy]

time 11:23 - done.

Now I need to go update my little features image thingy.

How did I do this so fast?

Simple, way in the beginning of this I realized some core functions needed to be made and I made them. This whole upgrade was barely more than calling already existing functions. The only tricky part was making copy() return an actual copy and not just a reference of the various supported types*. If it wasn't for that I would have finished in like 5 minutes.

I also made it possible to use multiply operator to get a copy. I chose multiply because, first you have the main source and then you make a copy...resulting in multiple instances. Alternately, copy() can be used directly.

var someVar = myObject * ["childContainer", "grandchildContainer"];
or
var someVar = myObject.copy( ["childContainer", "grandchildContainer"] );
// someVar now equals a copy of grandchildContainer, which was nested in childContainer, which was an immediate child of myObject

you can use copy() without any args to get a copy of the entire object. I bet you could also myObject * null;


*supportedTypes - hmmm, I need more supported types. Currently I support Int, UInt, String, Float, Array, Dynamic, Bool, IntMap & StringMap. I need to add Dictionary, Vector, Vector3D, Matrix4, Matrix3...let's start there.

[MadGypsy]

I'm addicted to making these abstract types. Last night I started from the ground up on a new version of Key. My initial goal with Key was to make below possible.

myObject["key1"]["key2"]

...and that's exactly what the F I'm going to do. Don't get me wrong, there is a little place in my heart for my initial Key. It works very well. It was my first Haxe abstract and I got it to do all kinds of things. I just can't let go of the fact that I wanted to make chainable keys and instead I made array keys. It's time to upgrade my Key...and my skills. Really, the skills part is the only thing I have ever really cared about.

I'm in the air about what to name the new type. Below are some of my ideas.

Entity
Volume
Real
Widget
Struct //cause this technically doesn't exist in haxe

I like Real but the only problem is it will technically be Fake. Maybe that's what I should call the new type... Fake.

var object:Fake<Type_t> = new Fake<Type_t>();

naaaah. I'll worry about it later.

EDIT:
re: " My initial goal with Key was to make below possible. myObject['key1']['key2'] "

correction: My initial goal with Key was to make key access possible on Dynamic values. The thing is, Dynamic values can contain Dynamic values so, it only makes sense that keys should be chained. If myObject and myObject['key1'] are both Dynamic and supposedly Dynamic can be keyed, chaining keys is unavoidable. Yet, my current Key script does not allow that.

[MadGypsy]

I totally did it. Currently this abstract only accepts Dynamic and Array types but those seem to be working fine.


The code for the abstract is practically nothing, at this time.


The problem, what has always been the problem, is that all values are being returned as Real<Dynamic>. What if the value is a string, int, any simple type? Now those return values have all these getters/setters and other code attached to them. This is why Key ended up the way it did. There is no way that I can figure (or maybe even possible) to return selectively. So, yeah, sure, this works but, it's not good.


----

I know what to do. Here's where this whole thing is taken to another level.

I need to make 2 classes, an interface and an abstract

The classes will represent

*every type that uses a field
*every type that uses an index

the interface will simply define the structure for both and give me a basetype to generically refer to both classes with.

The abstract will be either a field class or an index class based on its source input. Those classes can return things very differently from each other.

[Dutch]

+1 for 'widget' as a name

[MadGypsy]

The main reason I'm not going to use widget is because it's been so strongly defined as any little doodad or thingamajiggy you can embed on a webpage. I'm using Real right now but, I'm still considering Volume.

I have to admit that this is really hard. For one, there's a vicious circle to overcome. For two, I went from @:arrayAccess to using like half the possibilities of...whatever you call @:thisStuff. It's like taking your first step and then deciding you are going to tackle swimming, lol.

edit: @:thisStuff is called metadata and there are a whole bunch of them that do a lot of powerful things. When I use metadata I almost feel like I'm not supposed to mess with it...lol. Like I'm just begging my programs to hate my guts.

[MadGypsy]

I need a word.

A key would be a situation where each key represents itself

BoxA["boxB"]["boxC"] <- you could chop this on a key and get an instance of where you chopped. For instance, BoxA["boxB"] is an instance of boxB

but this, there is only ever one key to chop and you always end up with BoxA

BoxA[["boxB","boxC"]]

So the "key" is not really a key at all. It is a coordinate system...a navigation description. Maybe a route...ROUTE!

Nevermind I know the word.


----

I have to forego attempting to make real keys on a dynamic object. There is simply no way, and if there is a way it s beyond my skills to create it. I don't feel bad about that. This feature does not exist in ALL of Haxe. I promise you there are people that wish it did and yet, it does not exist. This can only mean 3 things

1) it is seriously impossible
2) there is some super technical reason why it is a bad idea
3) among thousands and thousands of contributors over more than a decade of time nobody has thought of it

I'd chalk #3 up to HIGHLY unlikely, which just leaves 2 really good reasons not to bother.

All that being said, I am going to stick with my original Key script but rename it to be more accurate ~ Route

I do intend to make an upgrade though. The whole abstract is going to fall back on a class. The getters/setters in the abstract will determine the type of value it is dealing with and forward the data to the proper method in the class. This will allow me to specifically type values. I'll give good examples of what this actually means when I get it working.

[MadGypsy]

I'm waiting for something to finish so I would like to expand on

3) among thousands and thousands of contributors over more than a decade of time nobody has thought of it

The bottom line is, they did think of it and they called it Map which is an abstract for StringMap, IntMap, HashMap, ObjectMap and SomeOtherMapIForget. That's all well and good but, what if your data is from JSON? Json data is parsed to Dynamic. It would not be hard to write a Dynamic to Map parser but, that is not ideal because it is changing the Type entirely just to add key access. Not to mention you lose other stuff that comes with reflection of a Dynamic.

Another thing to consider is, what if the Dynamic did not come from JSON and has types in it which need to stay the type they are. Converting to map may break this. The beauty of my Key abstract is that it went beyond only considering Dynamic, left types alone entirely and created a unification syntax for them without suppressing expected features of that type.

So, to go full circle to how I started this post, sure, a keyable type was created long ago but, all it does is create a keyable type. It does zero about Dynamics being keyed.

It breaks my heart that I can't properly solve this problem. If I could, it would be 100% like I am a contributor to the Haxe project. My abstract would belong right next to Map in the top level haxe source. ie... there would be no importing of my Type. It would be directly available everywhere in a project...a global type

[MadGypsy]

A couple of weeks ago I started on this thing where I wanted better API's to use in Haxe. I created my own ByteStream and ByteBlock classes that make dealing with bytes completely straight-forward. It works on all major platforms (maybe minor ones too???) and I achieved it without a single compiler condition. I then moved on to keys. I will admit that I partially failed at this but, really only syntactically cause I still have a heavily unified object type that gets rid of reflection entirely. It some ways it is also beyond my goal as I never intended to unify anything. I just wanted keyable Dynamics. Not to mention all the extras (like toJson and auto-expression parsing) that I also didn't intend but will be useful. During this time I had to go back to my expression parser because it wasn't compatible with JavaScript. It wasn't compatible with JS because I was using look-behinds in my RegEx and JS does not support that. I created a fix that was better than using look behinds while maintaining major platform compatibility, without using a single compiler condition. That brings me to my next thing.

Now I am going to rewrite the regular expression API to be compatible on all platforms for every imaginable expression feature. My expression parser fix will kick it off. In a lot of ways this will be a wrapper for EReg but, it will be putting EReg on steroids.

When I finish that I am going to make it possible to convert bytes to templated keyable objects.

When this is all said and done, numerous things that generally require a bunch of lines and retyping (with barely different guts) will be whittled down to one line. Parsing files will be little more than creating an object representation of the specs and sending it as an argument with the bytes to the constructor of some abstract. All the various container types will no longer require consideration of their type before using them. It is all unified to the one Key syntax but, it's also possible to deal with each type as normal while it's a Key.

In other words, I'm making it easier and easier to program in this super powerful language and maintaining major platform compatibility is not negotiable. If I end up using a compiler condition somewhere I could live with that but, so far, I have managed to literally make one version of script work on everything.

everything = [flash, c++, javscript, neko, android]

it is entirely possible that my code works on a hell of a lot more than that. It is also probably a given that my code works on at least some more than that. I can't think of anything in my code where ex: Java or Python would be like "Oh, Hell no!" (lol). It works on c++ so, what reason would I have to believe that C or C# would have problems? I'm not saying they couldn't.

[MadGypsy]

I've had some little ideas that I wanted to test, mostly just trying to get more experience working with abstracts. I invented an enum that sets iteslf.



The code on the left is the enum and abstract. The code on the right is my utilization of the abstract. The output panel contains the results of all my traces.

This is all really quite simple.

VType<T>(Supported_e)

This just means that I am creating a new type (VType) that can accept a value of an unknown type(<T>) and at runtime it's actual type will be (Supported_e);

new(t:T)
simply allows me to dump whatever in the constructor but T will now specifically equal that type. This is unnecessary info in this current case. If I had more than one function I may need to reuse that T to keep compiler type-checking working.

everywhere there is...

this = something

...as far as the compiler is concerned this is an Supported_e so I get the same results as if I did it like this

var typer:Supported_e = IsUnsupported;

This little script really doesn't make anything better in this world but it does neatly package a little type-check system