I just thought that Classes Are Context.
Why Is The First Arg Special? What does Multiple Dispatch have such a different syntax? What is common?
The interpretation that Classes Are Context means that we have functions (OO: methods) that are applicable in a certain context (OO: class). This can best be seen when the object the method is called on/sent to/dispatched on is left out ('inferred from context"). I.e. when we write
f(x,y)
instead of
this.f(x,y)
the "this." can be inferred 'from context' - namely the surrounding class.
Multiple dispatch in this setting would then look like this (making the context explicit):
(shapes,printing).printAt(figure, printer, center);
Where figure is from shapes and printer is from printing (meaning roughly figure instanceof shapes and printer instanceof printing).
Of course multiple dispatch is typically not written this 'first arg special' way, but it could.
What remains is how the functions/methods are declared. The usual way with OO is to group methods "in their" context (aka class). Nice Language (and other) skips this grouping. But grouping is only one way to specify implicit context.
Maybe the old with(x){} syntax deserves a revival?
What do you think?
Classes might act as contexts when operating in a role as namespaces (though allowing classes to act as namespaces violates One Responsibility Rule and is poor language design), but I'm not certain what you see as being special here. In the sense of Explicit Management Of Implicit Context, which I see you mentioned below, all parameters are equally part of (explicit) 'context' (excepting possibly the 'this' identifier which may be implicit within a method handler).
But the 'this'-parameter was exactly what I meant. I made this explicit with an example above.
With this view classes do not have a special role but are a special case of context - Syntactic Sugar in a language which supported more general contexts. So using them cannot violate the One Responsibility Rule. -- .gz
In most languages the use of 'this' makes the object the context, not the class. In particular, 'this.f(x,y)' or 'f(x,y)' might refer to a function defined in some subclass of the calling class. Based on what you're saying above, I believe it would be more accurate to say "method handlers are executed in a context implicitly associated with an object" than it is to say "classes are context".
Yes. Great. That is a good summary and clarifies my Thinking Out Loud. Can we make this into a short Wiki Word?
But doesn't it follow from this that classes (which are associated with the object) are at least part of the relevant context? Would Classes Are Part Of Context or Classes Are Special Csae Of Context do?
Class could be considered part of implicit context when accessing properties associated with the class (as a whole) rather than the instance/object. Static variables, constant data, Meta Object Protocol, various forms of Template Metaprogramming, etc. would fit in here. OO in general doesn't need classes, of course, so I wouldn't look for anything fundamental here.
I don't think that this is a new concept either. Rather that it is a small insight which places the role of classes in the larger context of contexts (sic). It also might show an easy migration path for developers used to classes as such. -- .gz
Classes provide a context for their members. each member is tightly coupled to the other members of the class. I call this Tight Field Coupling. The context can also be considered hard coded context. When the class is used as a component of another class, then that other class provides additional context for a member. When you serialize into XML you can actually see the context of each member in a hierarchical relationship to the other members. My research is focused on providing Loose Field Coupling for members using Information Oriented techniques based on En Demes. This will allow us to go beyond hard coded context. -- Jon Grover
See original on c2.com 