A radical view?

[David Semeria]

Hi Guys,

I looked at traits.js and I think it's very elegant.

Just one quick point though. Is encapsulation part of the solution, or
part of the problem?

The use of libraries like traits.js to construct object properties and
methods is well established, but in my view these techniques have the
capacity to reduce interoperability rather than increase it. This is
because each object type will generally have a different underlying
structure, thus making it hard to write generic library functions to
manipulate them.

It may sound heretical, but I believe using a generic (hierarchical)
representation for all data can lead to some very relevant reuse/
interoperability benefits.

Regards

DS

[Tom Van Cutsem]

Hi David,

If you are talking about a data representation format, I share your view. Much of the power of S-expressions and alternatives stems from exactly that property.

However, when you're talking about an object representation format, there are other factors to consider. I think the one compelling feature of object-oriented programming is that it bundles data with behavior (methods), and only the methods know about the representation of the object's data. Encapsulation naturally leads to abstraction, and the ability to change the data representation without impacting clients.

Now, with regard to traits.js there is an interesting dichotomy: the objects _instantiated_ from a trait are represented as black-box abstractions that encapsulate their state, but the traits _themselves_ are represented using a very open data format. In traits.js, we explicitly chose not to represent traits themselves as black-box abstractions than can only be manipulated by the operations defined by the API. Instead, traits are defined as "property descriptor maps". This is a data format used in the latest Ecmascript standard, e.g. as argument to the built-ins Object.create and Object.defineProperties. Because the representation of a trait is "open", it's possible to write generic functions that operate on traits.

On a final note: I believe your heresy was shared by Alan Perlis, when he noted that: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." :-)

Cheers,

Tom

--
To unsubscribe, reply using "remove me" as the subject.

[David Semeria]

Tom, thanks for all that, and in particular the link to Perlis quotes.
I particularly enjoyed the clever paraphrasing of Wilde, "A LISP
programmer knows the value of everything, but the cost of nothing" ;-)

I apologize for not focusing on traits.js itself - as I mentioned,
this is because I like it. The only minor quibble is that in general
I'm not comfortable with touching Object.prototype since it forces
every for..in construct to test for hasOwnProperty - although (i) this
is in reality an issue with the language itself and (ii) in any real-
life situation you have to do this anyway because you can never be
sure what other libraries do to Object.

As regards the wider issue of encapsulation in Javascript, I've got
quite strong views on this subject. These are based less on abstract
reasoning and more on many years of wrestling (in splendid isolation)
with these issues in a working environment.

I don't want to pollute the thread, so I'll just say that when it
comes specifically to the web, the undoubted benefits of encapsulation
are probably outweighed by disadvantages in terms of data portability
and the ability to combine code from different environments.

I'm happy to expand offline if you like (david-lmframework-com).

Best

DS

[Tom Van Cutsem]

I apologize for not focusing on traits.js itself - as I mentioned,
this is because I like it. The only minor quibble is that in general
I'm not comfortable with touching Object.prototype since it forces
every for..in construct to test for hasOwnProperty - although (i) this
is in reality an issue with the language itself and (ii) in any real-
life situation you have to do this anyway because you can never be
sure what other libraries do to Object.

I share your view that it's generally a very bad idea to modify Object.prototype. However, the traits.js library doesn't do that. In an Ecmascript 3 engine, it does define 2 methods on Object, but never on Object.prototype. What part of the library were you referring to when you mentioned being uncomfortable with touching Object.prototype?

Cheers,

Tom

[David Semeria]

On Apr 14, 2:11 am, Tom Van Cutsem <to...@google.com> wrote:

What part of the library were you referring to when you
> mentioned being uncomfortable with touching Object.prototype?
>

My bad, I looked at the code without running it. I did a few tests and
can now see you're right.

Cheers

DS