Classes Are Context

WhyIsTheFirstArgSpecial? What does MultipleDispatch have such a different syntax? What is common?

The interpretation that ClassesAreContext 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). NiceLanguage (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?

-- GunnarZarncke ThinkingOutLoud

Classes might act as contexts when operating in a role as namespaces (though allowing classes to act as namespaces violates OneResponsibilityRule and is poor language design), but I'm not certain what you see as being special here. In the sense of ExplicitManagementOfImplicitContext, 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 - SyntacticSugar in a language which supported more general contexts. So using them cannot violate the OneResponsibilityRule. -- .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 ThinkingOutLoud. Can we make this into a short WikiWord?

But doesn't it follow from this that classes (which are associated with the object) are at least part of the relevant context? Would ClassesArePartOfContext? or ClassesAreSpecialCsaeOfContext? 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, MetaObjectProtocol, various forms of TemplateMetaprogramming, 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 TightFieldCoupling. 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 LooseFieldCoupling? for members using InformationOriented techniques based on EnDemes. This will allow us to go beyond hard coded context. -- JonGrover

TryLikePages MarchZeroNine

CategoryContext