Tag: design

Collections and Operator Overloading NOT in JS

Well, that was almost a disappointment for optimising ordered collection renders by using arrays. But I have an idea, and will keep you informed. You can check the colls.js as it evolves. I wont spoil the excitement. The class in the end should do almost everything an array can do, and more. Some features will be slightly altered as it’s a collection, and not just an an object with an array prototype daddy. The square brackets used to index arrays are out. I’m sure I’ve got a good work around. I’m sure I remember from an old Sun Microsystems book on JavaScript text indexed properties can do indexing in the array, but that was way back when “some random stuff is not an object” was a JS error message for just about everything.

One of these days I might make a mangler to output JS from a nicer, less coerced but more operator coerce-able language syntax. Although I have to say the way ECMAScript 6 is going, it’s a bit nuts. With pointless static and many other “features”. How about preventing JavaScript’s habit of just slinging un-var-ed variables into the global namespace without a corresponding var declaration in that scope? The arguments for and against are easy to throw a value to a test observer to debug, versus harder to find spelling errors in variable names at parse time. If the code was in flight while failing, then knowing the code will indicate where the fault lies. For other people’s code a line number or search string would be better. Either works for me.

My favourite mind mess would be { .[“something”]; anything; } for dynamic tag based on the value of something in object expressions. Giggle.

Spoiler Alert

Yes, I’ve decided to make the base array a set of ordered keys, based on an ordering set of key names, so that many operations can be optimised by binary divide and conquer. For transparent access a Proxy object support in the browser will be required. I may provide put and get methods for older situations, and also because that would allow for a multi keyed index. The primary key based on all supplied initial keys and their compare functions to use and the priority order [a, b, c, …], and automatic secondary keys of [b, c, …], [c, …], […], … for when there needs to be so, I’ll start the rewrite soon. Of course the higher operations like split and splice won’t be available on the auto secondary keys, but in years of database design I’ve never could have not been one of such form.

The filt.js script will then extend utility by allowing any of the auto secondaries to be treated as a primary on the filter view, and specification of an equals, or a min and max range. All will share the common hidden array of objects in a particular collection for space efficiency reasons. This should make a medium fast local database structure possible, with reasonable scaling. Today and tomorrow though will be spent on a meeting, and effective partitioning strategy to avoid a “full table pull requests” to the server.

Further Improvements

The JSON encoded collation order was chosen to prevent bad comparisons between objects with silly string representations. It might be extended, such that a generic text search, and object key ordering are given some possibility. This is perhaps another use the compression can be put as BWT in the __ module has good search characteristics. Something to think over. It looks as though the code would be slow depending on heavy use of splice. This does suggest an optimization by making another Array subclass named SpliceArray which uses an n-tree with sub element and leaf count and cumulative tally, for O(1) splice performance.

Models, Views and Controllers

Had an interesting meetup about Android wear. All good, nice introduction to the new Complexity API, and general revision on optimization for power and other resources. It did get me thinking about MVC design patterns, and how I’d love the implementation to be. Model instantiate, model update, a model save callable, a view renderer, and a control list builder from method parameter signature. Very minimalist.

Initial thoughts indicate that the ordering of the controller events should be done based on the order of method occurrence in the class file for say Java. Also supplying a store state to the instantiate, and as a parameter to the store callback would be good. Like a Bundle. The renderer just needs a graphics context, and the controller callbacks need a unique method name (with some printed name mangling), and a boolean parameter to either do, or request doable for a grey out, and returning a boolean done, or doable status.

Synchronized on thread can keep mutual criticals from interfering, and a utility set of methods such as useIcon on the doable control query path could set up the right icon within a list with icons. This is the simplest MVC factorization I can envisage, and there are always more complex ones, although simpler ones would be hard. For post-process after loaded, or pre-process before saving, there would be no essential requirement to sub factor, although overrides of methods in a higher level object MVC may benefit from such.

Method name mangling should really be combined with internationalization, which makes for at least one existential method name printed form and language triad. This sort of thing should not be XML, it should be a database table. Even the alternate doable test path could be auto generated via extra fields in this table and some extra generation code, to keep the “code” within the “list field” of the editor. I’ve never seen a text editor backed by a database. Perhaps it could help in a “pivot table/form” way.

Just to say, I do like languages with a ‘ (quote) or “setq” or “Hold” method of supplying un-evaluated closures as function or method arguments. JavaScript has anonymous functions. Yep, okie dokie.