Rob,<br><br>There were some interesting ideas in the link you posted.&nbsp; The demos were interesting, and would be even better in Squeak without the need to compile, I think.&nbsp; They went by REALLY fast, though.&nbsp; I'd have to watch them several times to get a better feel for it.
<br><br>I've been thinking about the &quot;object experience&quot; quite a bit, and, unfortunately, it is still more of a feeling than anything solid.&nbsp; A lot of that feeling came from discussions with a co-worker around the similarities between [computer] languages as a sort of &quot;behaviour database&quot; and an actual database of any kind.&nbsp; &quot;Coding&quot; isn't much different than trying to turn data into information.&nbsp; &quot;Everything you need&quot; (as the Squeakers would say!) is right there...you just have to find it.
<br><br>Well, finding it means knowing what it is called, which is just one way of seeing, if you know what I mean.&nbsp; And seeing can be a funny thing.&nbsp; The old book &quot;Flatland&quot; made the analogy that if you lived in a 2D world, even a 3D object will look &quot;flat&quot; as it &quot;rises&quot; through the plane on which you reside.&nbsp; I think the visual element in programming can sort of be that third dimension.&nbsp; Now, I am NOT an object oriented expert by ANY stretch of the imagination, but it seems to me that that's what the original Smalltalkers found with their research, which is why we have mice and GUI's in the first place.&nbsp; So the challenge to me seems to be able to create that visual &quot;third dimension&quot; that would let you, to some extent, combine the functionality of your objects in a way beyond merely representing the underlying code, which is to say remaining &quot;flat.&quot;&nbsp; Perhaps this added dimension would actually help people come up with design patterns for their problems.&nbsp; Like I said, I have NO IDEA what that would &quot;look&quot; like--this is just a very intuitive feeling based on what I see as the organic nature of Squeak.
<br><br>Finally, I see such an &quot;experience&quot; as leading to the ability to use the &quot;answer&quot; from the functionality provided by an object within another object.&nbsp; The closest vision I have of this is layering query upon query in a database, sometimes with interludes of a make table for speed or when the combinations become too complex.&nbsp; But instead of turning data into information by connecting related fields, you would be connecting the underlying components of Smalltalk--messages--to create new functionality.&nbsp; It just seems like the impact on coding effort would have the potential to be similar to reading a complicated SQL statement with many joins and seeing the connections between multiple tables.&nbsp; I know there are holes in that analogy, but it's as close as I can get right now.
<br><br>So I guess, in the end, I am talking about a visual representation of the Model as well as of the View, if I have the lingo right.&nbsp; People have done a pretty good job with the &quot;View&quot; so far--I guess I just think you could do both.&nbsp; And, of course, you would always have the ability to see the underlying code representation of these interactions.
<br><br>At any rate, I'm always a big fan of trying to get where you're going by trying something out, and I just don't think you can go wrong trying just about anything based on what you are doing!&nbsp; You are ALL READY tying together real objects.&nbsp; The question I have is whether you could build a visual language extension for the View (a standard GUI builder) separate from a visual language extension for the Model and then find a way to &quot;connect&quot; them, or if you would have to have a better plan all along.&nbsp; Once I saw what you were doing, I figured I'd just try to reproduce what has been done to get a feel for it, then back up if I had to.&nbsp; The final &quot;complication&quot; seems to be how to make the widgets feel as &quot;live&quot; as possible since they do not live in the interpreted space of the VM.
<br><br>Yes, it's true, I am long winded...<br><br>Rob<br><br><div><span class="gmail_quote">On 12/1/06, <b class="gmail_sendername">Rob Gayvert</b> &lt;<a href="mailto:rtg@rochester.rr.com">rtg@rochester.rr.com</a>&gt; wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Could you expound on what you'd like to see in an &quot;object experience&quot;?<br>I've worked with a number of GUI tools, but nothing in .NET. Slashdot
<br>had a good article yesterday on this topic:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://it.slashdot.org/article.pl?sid=06/11/30/1523242">http://it.slashdot.org/article.pl?sid=06/11/30/1523242</a><br><br>Personally, I had planned on doing something like Interface Builder
<br>using XRC and MVP in some manner, but maybe this is old-fashioned now.<br><br>.. Rob<br><br><br>Rob Rothwell wrote:<br><br>&gt; Anyway, I guess I am offering to help because what I want<br> &gt; to &quot;do&quot; with wxSqueak is create a more robust, but
<br> &gt; &quot;realistic&quot; way of programming in Squeak for the masses--I<br> &gt; think you could go far beyond &quot;GUI builder&quot; to a true &quot;object&quot;<br> &gt; experience beyond what .NET and the like have to offer (again,
<br> &gt; another story), and it seems like that is at least similar to<br> &gt; the direction you are headed in as well.&nbsp;&nbsp;I'm not sure why this<br> &gt; is coming out of MY mouth, but why reinvent something if someone<br>
 &gt; is already working on it?<br><br><br></blockquote></div><br><br clear="all"><br>-- <br>The foolish reject what they see, not what they think; the wise reject what they think, not what they see.&nbsp;&nbsp;-- Huang Po