The
Gadgetorium
|
|
Wouldn't it be so beautiful?
If I only had a Brain! Description
Think of it this way: You really don't have to think about the underlying structure of the data, just the actual data themselves. It is really a filter situation, we have both, recall and display. Recall memories based on property values. It's really quite easy, even if I can't quite explain it completely. You kind of have to follow along with this. For a while to come. It's a work in progress.
Recall ("Names with: Color=Red", "From " & "Cars") will give you a list of all cars with a color of red. Memorize (What, In ) Recall (What, From) Forget (What, From) ReadProperty (Gadget, PropName) SetProperty (Gadget, PropName, PropValue) This is the key to "No More Table Editing". This schema eliminates the need to use any table editor. It does this by representing the Table Field Definitions as properties. Each Property of an object is just like a field in a table except for one important thing, it's added and edited "on the fly". The SetProperty method creates the equivalent of a new field/value pair and the ReadProperty method gets it back. Here's an example: Add a Table Old Way: Open Table editor and make 1 fields: Address with all the other crap such as type and length and... The Gadget way: SetProperty (Terry, "Address", "6430 N. N. Rd.") This effectively defines a new "Field" in Table Properties with: Name=Address Type=String (Char) Length=128 Index=True Value=6430 N. N. Rd. Oops, we need the City, State and Zip, too. Old Way: You know the drill. Gadget Way: SetProperty (Terry, "City", "Indy") SetProperty (Terry, "State", "IN") SetProperty (Terry, "Zip", "44568") Memorize (Terry, In) This just did in no time what the conventional wisdom would have us take much more time to do. Multiply this by all the tables and all the editing that occurs in the world all the time. The labor reduction is so great that it boggles the mind. Downside: It does eliminate the need to continually pay a lot of people for adding complexity to remembering stuff. I believe that this game is much simpler than those who are writing the rules think they know. Maybe they know it, they're just not telling us. Ha! I figured it out and, by cracky, I need to shout it from the mountain! I need converts. This concept needs to be advanced to it's logical end, which is: all data are represented in a standard format with properties and property values. Here's another thought. Think of a Gadget (read Object) as a completely self contained table that carries both the table definition and the value within itself. Each property is effectively a field definition, each value the field's value. So, when you define an object like this: Name = Terry Address=6430 N. R. City=Indy State=IN You have made a table with these "fields" like described above. This really does work. I have used the concept for at least 4 years and it has yet to fail me. I fail it quite often by not approaching a data situation correctly and adding a bunch of objects and properties I didn't need but, I add them damned fast. When you can create data this fast you tend to do overkill. I'll bet you a dollar to a hole in a donut that I can add properties faster than you can edit a "Table"!
This approach has led to the need for a new set of terms to describe it. These terms serves two purposes. First, it allows for specific communication about this technology and, second, it breaks the link between the old way of thinking about data and the new way. Here are the new terms for this concept.
Glossary Gadgix Gadgix is a Programming Development Environment based on the concept of "The Gadget". It takes programming from "Object Oriented" to being true "Object Programming". It is the Last Generation Language (LGL).
Linear Arrays of Consistent Objects (LACOs) LACOs are the organizational structure of the data. The underlying technology behind GDOs (Gadget Data Objects or Memories). A "Memory" is one Consistent Object. A bunch of "Memories" are arrays of Consistent Objects. These are stored in "Memory Pools".
A Memory. The basic element of data storage. A memory is based on the concept of a "Consistent Object" (CO). A CO presents a standardized way for the user and programmer to think of data. The structure of a CO is dynamically maintained. This means that the structure of the data is not tied to any database structure. All data are represented by: A Named Object with any number of dynamically assigned Properties.
VCG The Virtual Cortex Gadget. A Stand Alone ActiveX executable that does all the data to disk I/O. It organizes data as Linear Arrays of Consistent Objects (LACOs), a technology developed to eliminate all the unnecessary complexities of data manipulation. The paradigm is based on an attempt to simulate how a brain stores information. The mechanism is not the same but the analogy works for conceptual purposes. Memorize, Recall and Forget "Memories" from multiple sources like your local disk, the G-InterNet or another VCG enabled computer on the Web.
MEG The Memory Extension Gadget. The generic user interface to the VCG. MEG introduces the concept of storing "Memories" in "Memory Pools". This product radically changes how things are represented in electronic form. It also enables us to redefine data manipulation on the web by permitting users to distribute data amongst themselves by simply allowing every MEG enabled computer to expose selected memories to any other MEG enabled computer. This is the G-InterNet concept.
The G-InterNet is aimed at creating a data standardized version of the internet that is based on the Gadgetorium Technologies and concepts. Once the MEG product is fully web-aware, that is where every MEG can handle data regardless of its source, we have a very powerful way to build our own version of the internet. This portion of the project ties all the pieces together into one seamless application that shares data in a consistent manner, everywhere. And, after all, is consistency not a good thing?
|
|
|
The
Gadget Aware Programming Method is a way to keep from doing any database
structure changes. It allows you, the programmer, to focus on the
manipulation of the data more than the manipulation of the data structure.
How? By allowing you to forget everything related to database structure you can
devote all of your energy to defining what you store, not how you
store it. Just think about how much time you spend in the "table
editor". Imagine never again having to do that. I did and now,
for the last 3 years I haven't had to.