Classes Are Context

I just thought that ClassesAreContext.

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


See also ExplicitManagementOfImplicitContext, DoubleDispatchExample

TryLikePages MarchZeroNine

EditText of this page (last edited July 9, 2010) or FindPage with title or text search