The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Symbolic Instance Variables

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
James Robertson

Posts: 29924
Nickname: jarober61
Registered: Jun, 2003

David Buck, Smalltalker at large
Symbolic Instance Variables Posted: Jun 12, 2005 2:04 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by James Robertson.
Original Post: Symbolic Instance Variables
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
Latest Agile Buzz Posts
Latest Agile Buzz Posts by James Robertson
Latest Posts From Michael Lucas-Smith

Advertisement

I promised another post on my language ideas so here we go. I've got a spare bit of time to do the brain dump.

First off, let's make an assumption that Peter from smalltalk.org clued me in on: Let's assume that Smalltalk is Assembler and that there is a whole new realm of high level languages out there yet to be discovered.

We can see that this is starting to happen already. The biggest example is Croquet. It's a whole new paradigm of development for a whole new paradigm of computing - built off Smalltalk. Peter's example is Zuko which is also built from Smalltalk.

So given that we're blue skying, one thing we can try and do is give our systems more meaning. What does that mean? Well generally, it means less data and more information.

The Metaclass structure is one example where we get information from our system. By having it, we get tremendous reflection. Without it, we have no way of reflecting on our information and new organisation. One cry that arose out of my last post was that I was dumping classes which were really useful.

Okay, so instead of classes, let's say we have Prototype's. Prototype's are prototypical objects for something.. eg: a Cup. One interesting thing about Prototype's is that the "deep" hierarchies problem you get with classes doesn't exist. The structure to get to a Prototype is artificial and only meaningful when you want to see how code is inherited.

So how do you recognise a Prototype? In Smalltalk you recognise a Class because it subclasses form.. well.. Class. I think this is a bit of a waste personally. Why force something to "subclass" just to give it a symbolic identity.

While I'm on the subject of symbolic identity - why is it we name instance variables? Presumeably it's so we know what they are - right? Well, interesting you should say that (even if you didn't ;>). A name is only useful to a human. Computers need something more for it to be useful - take the Metaclass hierarchy - it's complex, but not too much. It's just complex enough that a computer can use it.

So what if I say that I think instance variables are crime against programming? - Instead, we should be describing relationships and associations. When I say "children" do I mean tree nodes, literally the children of a person, or something else entirely. If it's on a Person, a human can assert that it's literally the children of a person. But that's not good enough - our machine should be able to know this too.

So instead of having names, let's have relationships. I'll say that Person has children "the kind that are actual children" and a TreeNode has children "the kind that is a structure".

Now to go back around on myself, if I want to identify a Prototype, I relate to it from my Package that "said object" is a Prototype by having a prototype "the language concept" relationship to it.

This has a lot of implications. I can now write components that traverse known relationships. I can allow any object to have structure:children relationships and I can then make a widget that knows how to render a Tree from structure:children relationships. Now -any- object structure in the system that uses that kind of relationship can use my relationship!

In fact, code browsers would be following various kinds of relationships, such as "prototype" or "package" or "method". We are now modeling information in our system. Instead of having method names and instance variables, we have relationships that end at some data or a method. On my Person I can now have genealogy:children, security:children, genealogy:parents, security:parents and they know the difference. I can now render my Person in a security editor and also render my Person in a genealogy editor!

Now that we're unconstrained by the kinds of relationships we can make in the system, we can also extend the system at infinitum. If I wanted to add a comment to each method in the system, I'd simply write a comment editor which used and made metadata:comment relationships to methods in the code browser.

Remember - I dumped instance variable declaration? Here's the implication - I could attach my comment editor (hell, metadata editor) to any object in any subsystem of my application.

Pretty powerful eh?

Read: Symbolic Instance Variables

Topic: Things we would like to know Previous Topic   Next Topic Topic: Partial Adoption for Agile Approaches

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use