“Super Objects” are large and general “primitive” objects that can be used to implement a great many things, very intuitively & cheaply.
Imagine a very large “generic” object. (Let’s ignore classes for now.) This object has many “conventional” attributes. Here are some of the attributes it has:
Probably more than just this; This is likely conservative. The idea is that these objects are large, and that these objects are general.
It’s sort of like a file, because, see, it’s got a giant section of text, and it has a name, and it has a unique number (sort of like an iNode,) and it’s got permissions. It has parents (parent directory?), and it can have children (if this is a directory, not a file?) But it’s not quite a file, because it can have neighbors, and relations, …
It sure looks like one! We’ve got a parent, children, and so on. It also has metadata – key-value pairs, that can be used as the attributes on the XML node. It looks a lot like XML, too! But, what’s this “future” and “past” about?
Could be– you could use future & past to talk about later or earlier versions of the thing.
We have tags, a category, title, body, future and past, …
So the idea is to make a very large “object,” that can play all these different roles. Alan Kay used the metaphor of a “theatre,” and the objects as intelligent actors, that can play different roles up on stage – even the trees and the mountains are played by actors.
You can write a number of useful functions on the generic super-objects here. You can (for example) write code to make it possible to e-mail a thing to an address. You can (for example) write code to make it possible to generate an RSS or ATOM feed for a sequence (using past & future.) You can treat these as generic things, and say, “Give me everything of Category C,” or “Give me everything tagged foo. Order them by number.” The different attributes suggest different rules (You can have only one category, but multiple tags,) and ways of interacting with the things.
“What if I want something custom, that it can’t do? I want versioned (past/future) blog entries, that are also in time (past/future)?” The dilemma is that we have two things using the “past” and “future” capabilities, in different ways. In this case, get creative: use the “past” and “future” to refer to the blog-posting timeline (the main thing you care about, and which buys you the RSS feed,) and then use “next” and “previous” for your versions.
These can be wiki pages. These can be individual items of lists within the wiki pages, that are themselves these objects. You should be able to put objects inside objects. They can be anything. The idea is to use them for WHATEVER purposes you want.
Alan Kay wrote: All objects are “The Same.” – I think this general concept is what he was talking about.
This is pretty much exactly what VOS (see InterReality) is for. A Vobject is just such a “large” or generic object. Properties like the ones you list are actually other Vobjects that are linked to the first, with labels such as in your list (so, in fact, two ‘parent’ Vobject can share exactly the same ‘child’ Vobject, with either the same, or different, labels). To find out whether an object has properties (i.e. links), you check whether it has a certain type or interface in its type set (or you can just check to see if the property is there, but the explicit type set allows you to build constructs in some programming language that automatically associates classes with Vobject interface types.) “id” comes from the VOS system itself. Properties such as tags or categories, creation and modified, authors, title, description, copyright info, are in the “it has metadata” type interface (called ‘misc:metadata’). Revision information will come from the VOS core system itself, but hasn’t been fully implemented yet.
Vobjects also send messages to each other to make stuff happen, and type interfaces define those too. Alan Kay’s actors metaphor is pretty apt, since the pattern that VOS follows in terms of message passing and the computations that are run in response to those messages is related to that, and called the Actor model (http://en.wikipedia.org/wiki/Actor_model).
Thanks for the explanation!
If you have an object that is the child of two objects, how do you answer, “Who’s your parent?”
HansWobbe, I believe this touches on some things we’ve been intuiting and talking about – the fluid propagation of ideas, code-points for individual ideas, structures and so on.
A general platform for the support of these ideas make so many things so damn easy.
I’m going to have lunch with AustinKing tomorrow, who really clarified this for me, by showing me the AlanKay paper, (though I’d picked it up from the ZeitGeistField a few months ago,) and I’m going to write a spike implementation within a few days. This is just incredibly exciting.
I do believe that there’s incredible cross-over potential and opportunity for wiki here.
If you have a compact, usable notation (WikiSyntax) for “things,” then you can express things within things, and expose everything on the web, both with a pretty presentation, and with a data representation. The permission system should make it possible to even put code in the space of manipulatable things.
I’m just shocked at the utility of this concept.
I’ve been “absent” for a while, and I have to say– a lot of it has been because of my experimentation with these ideas; I have Python modules, a test suite, and a few different wx GUIs I’ve written that work with these “cards.”
I should have named this page “CellularProgramming,” or something, because it’s inspired by AlanKay’s line of thought that we can envision single-class object-oriented programming: Putting structure for a program into a single class, and then using the orientation and connection of the objects to make the structure of the thing.
As an example, if you are programming a wiki, then this means that everything, as much as possible, is modeled as a page. The entire metaphor of the program is then centered on the page.
Plausibly, even the CGI response systems are implemented as a page. This may seem a bit strange, but then, note, that you may find that you get to manipulate the CGI response system by manipulating a page in the wiki. There is no need to go that far, though; You could consider CGI response systems as “outside the system.”
You could also make whatever page templating that goes on, a page. Somehow, an HTML string is constructed when a wiki page is served. Somewhere, in the OddMuse code, there is probably a template, or something resembling a template. Such a thing could be composed of a page, or a set of pages.
Whatever tasks need to be done, do via the data structures and mechanisms of the page. The concept of the “page” may stretch and expand, but that is embraced in this style. Simply make those “stretches” visible to the users of the wiki. If you find you need to attach key-value pairs to pages, for some piece of code to make sense, “work right,” do so.
We can think of this “CellularProgramming” as MetaphysicalCode (perhaps in the EvolutionarySpirituality tradition ) wherein the primary metaphor is the cell. I happen to be getting quite a bit of milage out of this metaphor, though. I have found that with it, come ideas like bootstrapping/gestation, prototype based development, and recursive data structures.
I want to rework the Venn Interface program I did for JohnAbbe to work with cards.py, and then I think I’ll prepare it all for upload on a projects page.
see also: SemanticRegion
Nice to see you back.
I fail to see the need for emphasis on a SuperObject, since it seems what you are saying could apply equaly to a MicroObject. In fact, there is an inevitable “continuum” of scale ( take a look at the great new Nikon “universcale” flash presentation - http://www.nikon.co.jp/main/eng/feelnikon/discovery/universcale/index_f.htm )
I tend to think of this as an ever expanding function of the resolution of the tools we can make and use - sort of in an infinite fractal way - but without the attendant ChaosTheory.
I’ll look forward to seeing your Venn Interface (I’ve use these diagrams a lot, but lately seem to make more use of nested Tables (probably since they are supported in WxWikiServer).
Yes, you’re quite right– there’s no need for the Super ; I just put that in, because I was trying to say, “These classes do much more than just one thing, and one thing well, which is typical of conventional OOP.”
Yes, unfortunately the term “object” is now so general as to be almost meaningless. Yet its generality is why the word “object” has become so useful in programming!
I’ve been recently thinking (and trying not to) about objects as “the data points of programming,” something akin to how we think about built-in types such as lists, tuples, dictionaries / hashes, etc.,.
AlanKay-serialization objects at a minimum, perform things like:
You get all it’s stuff “for free.”
Programming a system supporting this kind of thing feels more like construction of a simulation environment, and if it is programmed in a modular way, leads me to aspect-like programming; Chunks of code holding sections of the object simulation, and then if you want it to be extensible, (people to be able to offer more simulation sections-of-all-objects,) then you need connector points (leading us to aspect-oriented-programming theory.)
These are just stray thoughts that I’m trying not to have.
In E-toys, if you create an object, it has something like 8-10 pages of attributes. In SmallTalk, they bundle whole groups of interfaces into “protocols,” just large collections of interfaces, simply because they have so many and need some organizing principle for discriminating between them all..!
Trivial objects, with 100’s (1000’s ever?) of methods. It’s a very different vision of OOP.
Instead of coming at the problems of discriminating a large number of Objects and their Attributes, from the micro-scale; consider creating a general structure which can be easily manipulated with conventional methodologies.
→ Hwo:SuperObjects?.TheArray? = (http://www.communitywiki.org/odd/HansWobbe/SuperObjects.TheArray)
I don’t understand, but I think I’d understand if I could see it, so, please; A demonstration would be great!
I’m interested in the AgglutinativeLanguage idea, and I’m interested in general structures – I think I understand those parts. I don’t understand what the vectors and rotations are about though.
Lion… This “culled” section of a recent publication may help a bit. Its still not as clear as it could be, but it does develop the Spreadsheet example a bit further and that may be useful.
I suspect you may also gain a bit of insight regarding why I have been so very interested in your LocalNames work. After all, LocalNames can be thought of as personal tags. Assuming that our personal (computer) systems have a seamlessly automatic procedure for mapping yours to mine, we have any incredible number of innovative procedures that become possible, especially if they are properly designed to be relatively “unbounded” (effectively “infinitely” scalable).
I’d appreciate any comment you might care to make, simp-ly because I am still not happy with our explanations and continue to look for “representative” audiences that may prompt further refinements.