Access Levels

[Matthew Browne]

Hi all,
I'm currently participating in a discussion about introducing access
levels to Javascript. I'm posting the link here in case anyone is
interested, since I think DCI could benefit from some further thinking
about access levels as well.

https://github.com/tc39/proposal-class-fields/issues/15#issuecomment-319077505

In particular, I think my suggestion of an 'internal' access level could
be a useful way to indicate data class methods that shouldn't be public
but which should be available to roles.

[Egon Elbre]

Is there a tl;dr; version of the discussion?

As far as scoping and structuring modules; the approach that Go takes seems to be my favorite so far.

1. package = folder

2. private means you can access anything in the package

3. no circular dependencies when importing a package

Why I think these are a good solution:

1. package = folder: means you are creating better whole's rather than "isolated classes", the package works as a whole with specific purpose, where you have pieces that move around

2. private to package: allowing access from an other folder to private things means you are accessing (usually) fragile things at a distance; this is a problem that inheritance/protected has.

3. ensures that you don't get into a tangled mess of a packages

Obviously none of these are without downsides:

1. package = folder; expressing data structures feels a bit awkward in this approach

2. private; modifying at a distance is sometimes useful

3. usually runtime dependencies are circular, which means sometimes you have to use interfaces or other structures to avoid the direct dependency

+ Egon

[James O Coplien]

Den 1. aug. 2017 kl. 13.27 skrev Matthew Browne <mbro...@gmail.com>:

In particular, I think my suggestion of an 'internal' access level could be a useful way to indicate data class methods that shouldn't be public but which should be available to roles.

That seems to make sense to me only if the class declaration were scoped within the Role itself, or at least that Role’s Context.

[Matthew Browne]

On 8/1/17 7:55 AM, Egon Elbre wrote:

Is there a tl;dr; version of the discussion?

Well I can summarize my own opinion at least...basically I agree with Apple's blog post that 'protected' unnecessarily conflates access levels with inheritance. I elaborated in my comments here and here.

2. private means you can access anything in the package

I think you summed up some of the pros and cons nicely, but personally I see it as a considerable downside if there's no way to specify a property as private to just one class. Some implementation details have no business being accessible anywhere else, and I think it's good when the class authors can indicate that and know that they can change those details at any time without breaking anything.

But the idea of package scope, where package = folder, certainly makes sense and sounds very useful.

[Matthew Browne]

So are you asserting that if a role needs access to a given instance method or property, then it always means that the instance method/property should be public to the entire app -- aside from the above exceptions?

In any case, an 'internal' or 'package' access level could still be useful for other reasons in a DCI app...for example, two closely related Contexts that both need access to a shared method that shouldn't be exposed publicly because it's implementation-specific.

[Trygve Reenskaug]

I've never understood which evils protection on the class level protects against. What's needed is protection on the instanced level.  Class oriented thinking!

[Rune Funch Søltoft]

I think both have merit. I've worked with languages that had both. I mainly use access levels to protect separate use and implementation and I'm pretty restrictive. In that context it's the locus of implementation that's central and having access control on an object level then forces me to be less restrictive in my approach (at class level I can mark implementation details as private but if that means it's in accessible to other objects of the same type, there are cases where I'd need to make it public even though it shouldn't be used by objects of any other type) on the other hand I could use object level restrictions to help express how object state might mutate and this make it easier to reason about runtime behaviour. So the short version is that I use class level restrictions at compile time and object level (when possible) at run time and thus find them orthogonal 

Mvh

Rune

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Risto Välimäki]

Hi Matthew,

On Context level you are using Role methods and those methods from Data that are specified on Role contract, right?

If you can even see other methods from role playing objects, I think there is something really wrong, and something that not just might break, but something that will break fairly often. Therefore protection level on data classes should not matter, but the interface (role contract) matters. What is defined in the interface / contract, is usable from inside a Role method, and what's not defined, is usable neither from inside a Role method nor inside a Context.

-Risto

--

You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-composition@googlegroups.com.

[Rune Funch Søltoft]

Risto wouldn't those methods that fulfil the contract be accessible to other objects and not only to context/role methods?

Mvh

Rune

[Risto Välimäki]

Yes, since they would be public. Private/protected (or similar) instance methods would be of course invisible for role methods / contexts.

Well, I'm not strongly against the idea of "internal/package" level protection, but I kind of fail to see the real benefits here. I have yet to see any concrete example where that "internal" protection level would be useful. 

If those instance methods would be so Context / Role implementation specific, wouldn't the Role method itself be the right place for those algorithms? What happened to the notion about Data being relatively simple, relatively dumb and relatively agnostic to the Context? The "IS" versus the "DOES"?

-Risto

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-composition@googlegroups.com.

Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-composition@googlegroups.com.

[Rune Funch Søltoft]

> Den 3. aug. 2017 kl. 10.55 skrev Risto Välimäki <risto.v...@gmail.com>:
>
> What happened to the notion about Data being relatively simple, relatively dumb

What happened to contexts playing a role?

[Matthew Browne]

On 8/3/17 2:28 AM, Trygve Reenskaug wrote:

I've never understood which evils protection on the class level protects against. What's needed is protection on the instanced level.  Class oriented thinking!

Good point Trygve, and sorry - I was actually thinking of the instance even though I said "class". Although I think Rune makes a valid point that a static/class access level could be useful. But personally I think private (to the instance), internal (to the package), and public would be sufficient.

[Matthew Browne]

That's the scenario I was going to bring up as well. For example, consider Rune's Account implementation. What if we also wanted CheckingAccount and InvestmentAccount sub-types, as in Cope's original version, and we wanted to give them access to the ledgers object without exposing it publicly? (I suppose we would first need to put the ledgers role methods in their own nested context called 'Ledgers' or 'LedgerCollection', but that's a separate discussion.)

[Risto Välimäki]

Well, that's a good question. I'd say that nothing happened to that, since even though Data might be internally complex (eg. being an another Context or having some complex data persisting algorithms), it should be externally relatively simple, including the interface.

The question remains: what kind of external-context-aware methods (sounds scary and smelly to me already) would be needed to be exposed only to roles/context, but not to the other objects and why?

There might be cases, but I fail to see them yet without a concrete example.

-Risto

[Matthew Browne]

Oh, and I agree with this:

On 8/3/17 4:30 AM, Risto Välimäki wrote:
> What is defined in the interface / contract, is usable from inside a
> Role method, and what's not defined, is usable neither from inside a
> Role method nor inside a Context.

I wasn't talking about other instance methods, only those specified in
the contract.

[James O Coplien]

Den 3. aug. 2017 kl. 03.07 skrev Matthew Browne <mbro...@gmail.com>:

So are you asserting that if a role needs access to a given instance method or property, then it always means that the instance method/property should be public to the entire app -- aside from the above exceptions?

I think we need an example to motivate this. I find the discussion so far very unmotivating with regard to the need for something like this.

I think to solve it properly, you need either a capability-based architecture, such as was supported by the Intel iAPX 432 and, I think, its Ada compiler back around the late 1970s, or ACLs (access control lists) and protection domains as we did in C++/P in 1982-3. C++/P was a research effort into giving the appearance of programming on an object machine. Protection domains are a lot like Contexts that offer safe interaction between cooperating objects, and which make explicit what kinds of interactions are allowed between domains. We found that: 1. You need to implement accessability on an object level rather than anything that statically could be specified as a a property of source code constructs; 2. It needs to be context-sensitive, so a given member of a given object can offer different permissions to different clients (other objects), 3. It needs to be dynamic so it can change during run time (e.g., during different phases of initialization),  4. Whatever could be enforced at compile-time was enforced at compile-time, but 5. This mechanism has to be independent of both scope and access control.

The protection domain architecture was fully implemented in a prototype distributed switching system. The goal was to provide secure information hiding in a customer-programmable switching system. The hardware platform from Dave Ditzel was, I believe, the first VOIP switch in the world. We did new software for it in C84 / cfront, which was later renamed C++ (after the Orwellian reference). The system had other features such as transparent remote method invocation, as well as a high degree of dynamic binding and run-time symbolic lookup support.

It was during this research that I proposed the addition of the protected feature to C++, and that’s where that comes from. The static stuff did what it did, but it served mainly to keep cooperating programmers mindful of what object features should remain free to be rearranged or removed without impacting clients.

Legacy paper attached from my archives.

[Risto Välimäki]

[semi-OT]

So Jim, it's you to be blamed for "protected" keyword then ;-) It's a small world.

Btw. I didn't really buy all the arguments in the Apple blog (https://developer.apple.com/swift/blog/?id=11). I find it a moot point that "protected" is not being "protected" anymore if some of the subclasses do expose it trough a public method. Which is true, but applies to "private" as well, though not with subclasses (unless reflection is used). Essentially this kind of limitations are contracts and also conventions: what should be done. They do not prevent you to eg. take a memory pointer to a said "protected" or "private" property and modify it from there, but they communicate to you as a developer about what's appropriate do do with that property / method.

Personally, I have found "protected" perfectly suitable for me in daily basis. Maybe someone could argue about having an additional "internal" keyword for helper-type C# extension methods to be able to access kind-of-protected properties, which aren't, but well...

-Risto

[James O Coplien]

Den 3. aug. 2017 kl. 13.58 skrev Risto Välimäki <risto.v...@gmail.com>:

They do not prevent you to eg. take a memory pointer to a said "protected" or "private" property and modify it from there, but they communicate to you as a developer about what's appropriate do do with that property / method.

+1

Yeah, that’s the idea, and that was the intent. Stroustrup always considered the access control to be reminders for work among well-meaning, cooperative programmers. You can subvert any of them with a few simple void* casts if you really want to… Protection domains were designed to simulate *real* security.

[Rune Funch Søltoft]

> Den 3. aug. 2017 kl. 12.44 skrev Risto Välimäki <risto.v...@gmail.com>:
>
> The question remains: what kind of external-context-aware methods (sounds scary and smelly to me already) would be needed to be exposed only to roles/context, but not to the other objects and why?

Just because I want an object to be able to play a role, why would I want every one to be able to use those capabilities? If I keep my role contracts private to the package implementing the context why would I want to break that scoping by forcing the methods of the contract to be visible to every one? I think any argument that true for private in a class world is true for a restriction between context and role player. When seen from the outside I can't see if the object is created by instantiation of a class of trough composition of roleplayers in a context. However in one case the argument is that an access restriction making it possible for the composed parts to talk together while no one else can use those capabilities is "obviously a good thing" while in the other case the question is "why would we won't to have that (same restriction capability). Personally I have had several cases where the role players were close to being an implementation detail of the context or at least the methods used in the context where, just like a private instance method in a class. The ability to split code in more coherent chunks than with class orientation doesn't negate the good things of keeping a narrow scope. Broadening the scope is rarely a breaking change narrowing it is

[Matthew Browne]

An interesting comment on the JS discussion thread (and yes, this is related to our encapsulation discussion more generally):

@mbrowne

With the private.x syntax, how would you access a private field on a different object of the same class?

Why is this seen as a requirement?

I spent a lot of time questioning this too, but the case that convinced me was that this enables things like binary methods:

class User {
  #socialSecurityNum;

  constructor(ssn) {
    this.#socialSecurityNum = ssn;
  }

  isSamePerson(user) {
    return user.#socialSecurityNum === this.#socialSecurityNum;
  }
}

It also makes sense from a visibility perspective: If you have a private field, the only code that has visibility into it is the class's members. Thus, the logic that operates on the private field of one class instance is the same as the logic that operates on another class instance.

Moreover I couldn't find a compelling example of why this kind of visibility would be dangerous.

First, just to be clear on the syntax: the proposal calls for using the # symbol to indicate private properties in Javascript (which is of course a controversial syntax, but that's another matter). In the above example, #socialSecurityNum is a private instance property.

This seems wrong to me, except maybe for the last point since I can't think of any practical cases where class-level visibility would cause a big problem. But definitely philosophically wrong, at least assuming the intent is to be object-oriented rather than class-oriented (and fortunately the JS object model is rooted in real object-orientation).

But I'm not sure how best to make a case against it, and it's all the more difficult given that apparently most other so-called OO languages allow this kind of access to "private" members across instances when doing so within the same class (C++, Java, Python, PHP, and Swift to name a few).

I could of course just appeal to authority and quote what Trygve just said :) But I'd rather make a practical case, and currently class-level encapsulation for instance properties just feels wrong to me even though I'm not sure what concrete problems it would cause. Can anyone shed some light?

In the end, the committee may well move forward with the proposal as-is unless the negative effects of class-level encapsulation would be dramatically bad for JS for some reason. But even if they sadly move more toward class orientation, at least we would have clarified something here on this group :) Oh and BTW, I think class-level encapsulation still makes sense for private static properties.

[Matthew Browne]

On 8/3/17 9:20 AM, Rune Funch Søltoft wrote:
> Just because I want an object to be able to play a role, why would I want every one to be able to use those capabilities? If I keep my role contracts private to the package implementing the context why would I want to break that scoping by forcing the methods of the contract to be visible to every one? I think any argument that true for private in a class world is true for a restriction between context and role player. When seen from the outside I can't see if the object is created by instantiation of a class of trough composition of roleplayers in a context. However in one case the argument is that an access restriction making it possible for the composed parts to talk together while no one else can use those capabilities is "obviously a good thing" while in the other case the question is "why would we won't to have that (same restriction capability). Personally I have had several cases where the role players were close to being an implementation detail of the context or at least the methods used in the context where, just like a private instance method in a class. The ability to split code in more coherent chunks than with class orientation doesn't negate the good things of keeping a narrow scope. Broadening the scope is rarely a breaking change narrowing it is

+1

[Matthew Browne]

On 8/3/17 7:39 AM, James O Coplien wrote:
> I think we need an example to motivate this. I find the discussion so
> far very unmotivating with regard to the need for something like this.

I think the example I mentioned is a suitable one - CheckingAccount and
InvestmentAccount Contexts that both internally use an Account context
(implemented with ledgers) as a role player / nested context. Or if
that's not the right way to structure it, I'd be curious to know what is.

> The static stuff did what it did, but it served mainly to keep
> cooperating programmers mindful of what object features should remain
> free to be rearranged or removed without impacting clients.

This is exactly how I think of access levels - not as a security feature
but as a way to document intent and to discourage violation of
encapsulation...but not necessarily make it impossible, since it can
sometimes be useful for reflection (and of course really making it
secure is an entirely different goal).

[James O Coplien]

Den 4. aug. 2017 kl. 03.18 skrev Matthew Browne <mbro...@gmail.com>:

First, just to be clear on the syntax: the proposal calls for using the # symbol to indicate private properties in Javascript (which is of course a controversial syntax, but that's another matter). In the above example, #socialSecurityNum is a private instance property.

This seems wrong to me, except maybe for the last point since I can't think of any practical cases where class-level visibility would cause a big problem.

This reduces to what I have always held is a very wrong-headed approach to computation in so-called object-oriented programming languages: that a method “belong to” only one object at a time. This is usually orchestrated in the method’s class membership. So any question that comes up about inter-object access must be done on a class level, since the method is a member only of its class (and if you stretch the argument, of its superclasses).

Mature programming languages like CLOS allow an operation to straddle objects. My mental model is that addition operates on two objects — the addends — without anyone being in charge of adding the other to itself. The latter is a common mental computational model that most programmers hold, and it probably owes back to the dysfunctional message paradigm of Smalltallk. What I want is an operator+ that operates on two objects.

This problem was recognized very early in OO design, when we were trying to build models to teach people OO. Stroustrup’s book once had an example with a hierarchy of Shape classes, and another hierarchy of Window classes (XWindows, CursesWindow, SunviewWindow, NeWsWindow, etc.) and claimed that polymorphism made it possible to just be given a Shape object (of some Shape derived class) and a Window object (analogously) and dynamic dispatching would just make it happen. Bullshit. Try it in C++.

Tom Cargill and I discovered the same problem at about the same time. Both of us “invented” what is now called the Visitor Pattern at about the same time to be able to do this. At first I thought that there must be something I was missing, and then convinced myself that C++ must be broken — that Smalltalk must solve this problem. So I looked in the Smalltalk image to find out how they did heterogenous addition and — sure enough, they also use a complex set of patterns to promote and convert objects, to compensate for the fact that the computational model is based on single dispatch.

It turns out that C++ does have this form of polymorphism (selection of the algorithm on the basis of all parameter types), but it is bound by the compiler rather than by the object machine. It’s popularly called overloading. There are a good number of idioms, examples, and patterns about how to implement this in C++ for abelian types (http://tinf2.vub.ac.be/~dvermeir/c++/EuroPLoP98.html).

CLOS does the same thing, except the object virtual machine handles it all automagically at run time. Richard Gabriel (co-creator of CLOS, together with Guy Steele) has always puzzled over the GOF patterns, since he said he finds that he never needs them — his language, CLOS, supports these notions directly. Multiple dispatch is one of them. Wrappers and whoppers are another. And with reflection you can make it dynamic (as I described in a previous mail).

If you have multiple dispatch, then you have a reasonable computational model and can start reasoning about where to put in protections. The granularity now is finally right: accessibility between the unit of computation (which is the method and not the object) and the parameters to which it has accessed. Other languages tie themselves into a pretzel with artificial limitations that make all possible implementation approaches look ugly. So it is just a matter for people who have chosen single-dispatch languages to choose the option which is least ugly to them. To fix the accessibility problem you must first fix the dispatching model. If you’re unwilling to do that, I find the solution discussions to be about comparing big balls of mud, and I prefer to avoid those discussions.

[James Coplien]

Den 3. aug. 2017 kl. 12.43 skrev Matthew Browne <mbro...@gmail.com>:

What if we also wanted CheckingAccount and InvestmentAccount sub-types, as in Cope's original version, and we wanted to give them access to the ledgers object without exposing it publicly?

If you insist on doing this at compile time, and it is non-time-varying, use the C++ friend relationship.

QED.

[James O Coplien]

Den 4. aug. 2017 kl. 03.34 skrev Matthew Browne <mbro...@gmail.com>:

I think the example I mentioned is a suitable one - CheckingAccount and InvestmentAccount Contexts that both internally use an Account context (implemented with ledgers) as a role player / nested context.

If you are looking for a solution to that, I think C++ friends suffice.

[Matthew Browne]

My question wasn't based on any particular language and as such didn't assume the presence of any existing access modifiers such as 'friend'. But I agree that friend access could solve this nicely. Internal/access would also solve it, albeit being less restrictive in most cases, but I'm not sure that matters as long as there's some option other than public for instance methods used by roles.

--
Sent from my Android device with K-9 Mail.

[Matthew Browne]

Hi Cope,
If I understand correctly, you're arguing that access modifiers for methods should apply to the method itself - so neither class-level nor instance-level encapsulation. What about properties?

And it sounds like you're saying that access modifiers for languages with only single-dispatch -- most OO languages including trygve -- aren't even worth discussing here. Did I understand you correctly?

--

[James O Coplien]

Den 4. aug. 2017 kl. 19.09 skrev Matthew Browne <mbro...@gmail.com>:

Hi Cope,
If I understand correctly, you're arguing that access modifiers for methods should apply to the method itself - so neither class-level nor instance-level encapsulation. What about properties?

And it sounds like you're saying that access modifiers for languages with only single-dispatch -- most OO languages including trygve -- aren't even worth discussing here. Did I understand you correctly?

As described in the paper I circulated (yesterday?) there are two loci to be concerned about: the point of access, and the point being accessed. There is a question of permission only when the two are interacting.

You can implement controls at either end, but the triggering of any responsive action must be at the accessing end. For most conventional programming, that is in a method. There are exceptions, of course, such as expressions in static initializers that access protected fields, but those are kind of an odd sub-case and can be viewed as syntactic sugar that extends access from the constructor.

In a protection domain model, both the accessing code (the method) and the accessed code (any instance member) have a domain attribute. Whether the access is allowed is determined by an M x M permissions table, where M is the number of domains. One end is a method. That method may get its domain attribute from its enclosing class, or it may be set with a run-time API, or it may be statically declared at compile time. But to view a “class” or an “object” as the accessor is nonsense. Classes don’t execute. Objects don’t execute. Methods do.

And you use the word “encapsulation.” Encapsulation, scope, access control, and visibility are all distinct concepts. Your question mixes them.

As for using such tools in a single-dispatch language, it’s just necessarily inconsistent when you deal with corner cases, such as the Javascript case you noted. With a class model, and assuming single dispatch, I think you just can’t do it. You can make it work most of the time. If “work most of the time” means “work” then you are right. It means “works some of the time."

There was a similar issue in early C++ with protected, as the “real C++ programmers” know. Consider base class B with protected member p(const B*) with class D derived from B, and p overridden in D. C++ implemented an attempt at instance-based access control enforced at compile time in the class system:

class D: public B {

protected void p(const B* that) {

     this->p(this);    // ok

     this->Base::p(this);  // o.k.

     B* self = this;

     self->Base::p(this); // not ok

     that->Base::p(this);  // not ok

     that->p(this);  // not ok

}

It became horridly confusing. Quick: which of these are legal?

class D: protected B {

protected void p(const B* that) {

     this->p(this);    // ??

     this->Base::p(this);  // ??

     B* This = this;

     This->Base::p(this); // ??

     that->Base::p(this);  // ??

     that->p(this);  // ??

}

[Risto Välimäki]

I have forgot already most that I ever knew about C++, so I cannot answer for that quiz, sorry.

Your example inspired me to check how things are working on TypeScript, that's one of the most prominent Javascript related languages. Actually TypeScript is a superset for Javascript (or correctly EcmaScript), adding classes, optional static typing and the latest and greatest ES next version specified, and sometimes proposed features. TypeScript is transpiled into EcmaScript (eg ES5,ES6 or ES7), so the browser (or Node.js or other environment) will actually run Javascript. Javascript itself is lacking those private/protected/public modifiers as well as classes, so lets try this in TypeScript:

class A {

    protected foo() {

    }

}

class B extends A {

    bar() {

        this.foo();

        this.baz();

        let self = this;

        self.foo();

        self.baz();

    }

    private baz() {

    }

}

Well, I have to see that I was a bit surpised to see that the above code was indeed perfectly legal according to the TypeScript compiler. Protection (or "privacy") by TypeScript compiler is only at compile time. If you violate the protection, you'll get an TypeScript compilation error, but the resulting Javascript code will work well, kind of. Actually it will work better than you expected or wanted, since actually all the properties and methods just happens to be (public) instance variables or (public) prototype functions on that object.

Btw. syntax "let self = this" makes a lot of sense in Javascript, because it's a common convention to pass "this" into (often anonymous) functions, callbacks and such. Though after using self-binding arrow functions from TypeScript (or recent enough EcmaScript), you almost never need to use that hackish "let self = this" syntax again.

Back to the example of yours: in that case you have, I think it's maybe a good thing to be able to call private/protected members only by using "this->" syntax. Less error prone and more obvious to me at least.

BR,

Risto

--

[James O Coplien]

Den 4. aug. 2017 kl. 23.19 skrev Risto Välimäki <risto.v...@gmail.com>:

I have forgot already most that I ever knew about C++,

Some would say that is a sign of intelligence.

[Matthew Browne]

I think it would help make this idea more concrete in my mind if I had some idea what the syntax might look like. I was just searching on Google and might have missed something, but it doesn't look like any existing language has direct support for multiple dispatch together with access modifiers that would work for the social security number example.

It seems to me you'd need a way to specify which properties the method should be able to access. Not a real suggestion, but for demonstration:

internal function myMultimethod(ClassA a {foo}, ClassB b) {
  ...
}

where foo is an instance property of objects of class A that myMultimethod should be allowed to access. This may be way off-base.

--

You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.

[James O Coplien]

I think we have ranged far into the realm of untethered speculation and almost random notions where it will be difficult to sort the relative benefits of an idea and its antipode.

[Matthew Browne]

Okay. I hope that someday there will be an effort to create a language that has support for both multiple dispatch and DCI. This discussion about access modifiers in combination with multiple dispatch could be deferred until then.

Sent from my Android phone

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-composition@googlegroups.com.

Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-composition@googlegroups.com.

Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-composition@googlegroups.com.

[James O Coplien]

Den 5. aug. 2017 kl. 18.18 skrev Matthew Browne <mbro...@gmail.com>:

Okay. I hope that someday there will be an effort to create a language that has support for both multiple dispatch and DCI.

Just do it ;-)

[Matthew Browne]

Haha, I think it's obvious I don't have the right qualifications to spearhead this effort, even if I had the time. Of course experts get to be experts by studying and taking one step at a time, so I don't mean to suggest that only someone with an academic background in language design could do it, but still...