@Michael Coblenz Does the fragile bass class apply to data? All the examples I can imagine are due to method inheritance, not data inheritance.

In prototype-based languages, the answer seems to be “inspect the object at runtime and see.”

But ultimately you need to write code that makes assumptions about what fields are there.

So you run the code once, see that field f is there in the debugger or whatever, assume it’s always there, and then later, BOOM.

methods or data, it doesn't make a difference, esp in js where methods are first class

Take a look at this visualization showing how a single empty visual element (shown in red) is linked with many tiny non-primitive objects. For example, we have a full object representing only border (depicted in blue) which, in turn, is made of other smaller objects.

We find the composition of explicit objects to be essential. In particular, in a live environment we want to be able to swap things at runtime and we want the views to update accordingly.

We apply this concept at all levels of abstractions. Above we see how even modeling of a single visual element can be split into tiny parts. Now, when we make some of those tiny objects behave like functions, we can get very interesting effects. For example, a common issue in user interface design is to adjust the look of widgets. Often this is set through a global theme. We want to be able to affect the look of a single widget. CSS is an interesting source of inspiration, but when people want to affect the structure of the DOM, they resort to JS. Not quite the most elegant combination. So, we introduced the concept of a look. Any element can get a look injected, and a look can affect everything in the element, including its structure and the way it handles events. The look is an object, but it acts like a transformation. Through object composition we can swap it in and out at runtime. In a way, a look is like a property of a prototype object (in Pharo, these would be called talents, or object traits). We find this to be quite powerful.

For example, here is a single label widget. By default, it is only a case that renders nothing and has no children.

But, when we add a look to it, the look adds an actual child that draws the text.

These are some examples that relate to the ui, but we apply these ideas to everything we build.

@Ivan Reese Does this address the question?

@Edward de Jong / Beads Project

the beauty of 3D instancing vs copying is that 3D objects are collections of triangles, textures, etc. which are all static in the sense that the component triangles don't affect each other. The more purely you enter the data domain, which is where Spreadsheets excel, the more tangible it gets.

Yes and no. In 3d, you hop up and down the ladder of abstraction at a blistering rate. Yes, you'll spend a lot of time working at the level of individual verts, edges, tris, faces, but even then, you care immensely about the relationships between them. For instance: if you keep a strip or a ring of faces fairly uniform, it's easy to grab the thing and work with it as a set; by keeping face angles or areas consistent, you create an ad hoc geometric abstraction, and the tools are designed to help you do this and leverage that. When you leave that lower level and start working with surface groups, meshes, objects, rigged collections of objects, etc., you're now working largely with nondestructive procedural modifiers, where tightly-controlled and well-understood relationships (and cross-cutting ones at that) become immensely important. So even though the data is at rest, so to speak, you still need to grapple with abstraction, structure, interdependence, sequence, declaration vs procedure, memory vs computation cost (both of the data and the transformations), and so forth. And then when you start adding animation, physics simulation, particles, etc., your data is no longer at-rest, and changes to your supposedly "static" data like geometry in the small can have rippling consequences in the large. And again, there are enviably rich tools for helping you manage it.

@Tudor Girba Yes! Your comments and screenshots were immensely helpful, thank you. I know so very little about Pharo and the GToolkit, and I owe it to myself to learn a lot more about these projects. From what I do know, they're seemingly the only things I can point to that share very many of the goals I have with my project, and have run into many of the same questions, and best of all have satisfying answers to those questions. To that end — I'd love to know what projects you are looking to as the high bar. What, if anything, is the existing work outside your own immediate sphere (so not Smalltalk / Self, say) that you would like to borrow from or build on? (As an example / aside: I had a 4 hour drive today, and I re-listened to your episode of the FoC podcast. You talked a bit about the importance of having a single render tree, so that the visual tools, introspection, etc. all work universally, and there are no dead ends where you hit a flat <canvas>-like thing. I'm working on that very same problem right now, but I think my solution is different. I allow multiple render trees, so you can use whatever rendering technology best suits each kind of data — SVG for SVG, GL for 3d, HTML for documents, etc. But each tree must be nestable, and able to generate input, and must have a way to render the editor GUI, so that it can fully participate in editing, introspection, etc.) The idea of "looks" makes a lot of sense to me. I clearly see the need, and the utility of this approach. You then go on to mention...

In a way, a look is like a property of a prototype object (in Pharo, these would be called talents, or object traits). We find this to be quite powerful.

I don't quite follow this simile, though. And — are these "traits" the same as in Self, or have they changed in the time since?