“Lexical” refers to relationships established by the structure of the source code. An inner class definition is contained in an outer class definition, so things in the outer class are called lexically visible from the inner class. In contrast, the superclass is only a reference in the source.

Yes, moving an outer class method to a superclass may indeed cause a behavior change, so strictly speaking in Newspeak such a transformation is not a refactoring.

The choice between implicit or explicit sends is essentially a question of API design. In a nutshell I’d say you design a module so that certain names are used within it to refer to certain things, and those are sent implicitly. I hope the next part will clarify this.

Danil:

No, that’s not something that class nesting is supposed to handle. Recursive structures can be created by simple object composition. Arbitrary depth, or varying composition patterns, or migration to different containers Bob suggested are all signs that the relationship between the classes is too “fluid” to consider one of them nested in another.

Are there circumstances when you would recommend “always do an explicit self-send if …”?

Hence migrating to a different container instance should not be allowed (unless with some type / class guarantees, which seems unlikely).

Some kind of message-sequence diagram leading all the way to DNU would make this quite clear.

Thanks

Does that mean (a) you look-up container instances dynamically to find lexically visible methods, or (b) compiling a container class method somehow update contained class methods, or (c) something else? Can a contained instance migrate to another container instance?

Is it possible to apply class nesting for implementing of recursive (i.e. tree-like) structures of arbitrary depth?

I’ll take the liberty of replying.
(a) No.
(b) If you make implicit receiver calls, yes. As the post explains – you don’t have to.

As for fragility – (b) can cause fragility, but we trade off one kind of fragility for another. The comb rule (a la NewtonScript) means that adding methods to superclasses can silently “capture” lexically apparent names. In contrats, the Newspeak rules mean that only local changes (e.g., removing a lexically surrounding method) can have such effects. These are much easier to see and track.

Would one rule be: if you want the contained instance to migrate to another container instance, don’t nest classes.

I am somewhat concerned about one thing: it seems lexical visibility requires (a) container methods defined before contained methods, and (b) container methods to not be inherited from container super-classes. Are both of these true, and, if so, do they make some things more fragile?