Object composition challenge (was: Using Object Literals as Classes)

David Bruant bruant.d at gmail.com
Fri Mar 16 16:18:48 PDT 2012


Challenge at the bottom

Le 16/03/2012 23:34, John J Barton a écrit :
> On Fri, Mar 16, 2012 at 3:04 PM, David Bruant <bruant.d at gmail.com> wrote:
>> Unfortunately, methods on prototype require to have properties that are
>> public.
>>
>> If you avoid prototype methods, all your attributes and private methods can
>> be shared by public method scopes.
> I think you are mixing up interface and implementation here, in a funky way ;-)
I was just talking about implementation.

> The interface of the 'prototype', a pointer to a table for fallback
> lookup, allows implementation inheritance. But it does not demand it,
> it's just a choice you may make.
>
> You can, for example, create an implementation hierarchy, then
> encapsulate it in a an interface hierarchy. The functions on the
> .prototype for the interface may be pointers to functions on the
> encapsulated implementation.
>
> Something like:
>
> var Foo = (function makeFoo(impl) {
>   function Foo() {
>     impl.call(this, ...);
>   }
>   Foo.prototype = {
>     bar: impl.bar,
>     baz: impl.baz
>   };
>   return Foo;
> })(theImpl);
>
> So prototype does not mean non-encapsulation.
I agree with you, but it's not what I meant.



I guess I should provide an example of the problem that is hard to solve
in JavaScript (ECMAScript 3 and 5). Here is the challenge !

A Person knows one secret and has methods like .eat(), .walk()... There
is no method in the Person interface to reveal the secret either
directly or indirectly.
A ComputerSavvyPerson is a Person, but has an additional
.getMD5HashedSecret() method which returns the hashed secret.
A StupidPerson is a person with a method .tellSecret()


I want to be able to create Persons, ComputerSavvyPersons, StupidPersons
and the secret to be properly encapsulated (only revealed by stupid
people through the dedicated method). I'd like to emphasis that the
secret belongs to the person and none of the subclasses. I could add
arbitrary subclasses and don't want to add a secret to each child subclass.
Last constraint : I want each type to be in a different file (no shared
private scope). This is important for code reuse. If I want to reuse the
Person code, I don't necessarily want to reuse all its subclasses.

This is a piece of cake with Java's protected. It is much convoluted in
JavaScript. I think this kind of problem being hard to solve in
JavaScript is the reason why so many frameworks like Node.js make the
choice to expose their internals.

David


More information about the es-discuss mailing list