A few questions and suggestions.

Thiago Silva tsilva at sourcecraft.info
Fri Apr 27 16:04:00 PDT 2007

I'm happy to have found this list, since I care very much about the
future of ECMAScript. As a student who is using ES for an academic
project, I'm looking for some answers and, pehaps, suggest a few
things (if I'm allowed to).

*** Exceptions

Currently, I really miss the ability to catch exceptions given it's
type. In the new ES spec, will the following code be possible?

Try {  ... }
catch(e : TypeError) {  ... }
catch(e : ReferenceError) {  ... }

*** Encapsulation

Another feature I miss in the current spec is the ability to deny
direct access to an object's property (internal state) without the
object itself being aware of such access/changes. I share the opinion
that using closures to access local variables and it's performance
impact doesn't seem to be a good choice as encapsulation mechanism.

Reading about the upcoming spec, I understand that the new class
notation with access control for members (public, private,etc) will
provide such mechanism. But I'm not a "class enthusiastic" when using
ES because I like the idea of expanding the class declaration (like in
ruby or smalltalk) to support highlevel definitions of an object, such
as the famous "has_many" and the like in Ruby on Rails. Therefore, I
appreciate the use of methods to define new classes of objects, such

  name: "Person",
  doc: "I define a Person object",
  attributes: "name email", //defines the properties, setters and getters
  methods: { ... },
  has_many: "pets"

But, when the new ES spec and implementations arrive, I fear that I
will have to chose between two approaches when creating classes:

a) Define a class object using "class" and be able to control access
to properties but not being able to extend the class notation (ie.
with "has_many" or "doc" above);

b) Define a class object using functions instead of "class" (like the
above approach) but not being able to control the properties access.

I didn't like very much the situation, so I ask: will/would it be
possible to support some mechanism to define access control on
properties? A reflection API offering such means, maybe? To

o = new Object;
o.name = "thiago";
o.name = "foobar"; //not possible.

Forgive the poor illustration. I appreciate having the access control
as (meta) data just as I appreciate having the property "prototype" in
the objects.

*** toSource()

I'm a great user of toSource(), so I ask: will it be in the new spec?

One thing I don't like about this function is that it ignores the
comments writen in the function bodies. So:

function f() {
   //say hello

f.toSource(); // retuns 'function f() { alert("hello"); }'.
//"//say hello" is not part of the source :-(

This is unfortunate, since I'm working on tools inspired on
Smalltalk's class browser, object inspector, etc. Using such UIs to
define classes, functions, etc, makes harder to maintain inline
comments (if viable, at all). Anyway, if something like toSource
becomes standard (and I hope so), wouldn't this make it more precise
when it comes to it's meaning?

*** Ruby's method_missing (AS's __resolve /  __call ?)

Other thing I miss: giving objects the oportunity to react to
"improper" usage. This was suggested and explained in the following


I also would like very much to see that in the new spec.

*** Function expression verbosity

Vassily Gavrilyak brought this in the thread:

I hope to see something like that as well, even tough, for what I
understood, it seemed harder to come up with a good alterative syntax.

Not willing to ressurect the discussion, but I would like to say that
I don't think, in any way, this is a matter of typing. I'm very
pleased with Smalltalk block's syntax not because I only have to type
a couple of brackets, but because a couple of brackets rightly and
soundly are identified as a block object, as much as a literal array
or object in ES. So, not much about compactness, but readability as
literal values (hope my english is right).

Anyway, I think "function() {}" verbosity suppress the desire one have
to brodly use it around the code as a literal value being transfered
to properties, parameters, etc.

*** Thank you

I appreciate the members attention and I'm sorry if some of those
issues are inappropriate, already discussed, or "too late" (it took a
while for me to find this mailing list). I wait for your inputs.

Thiago Silva,
mailto: tsilva at sourcecraft.info
jabber: tsilva at jabber.org

More information about the Es4-discuss mailing list