«

Hello All,

Does anyone have any knowledge of when version 4 will be released? I
think that version 3 was finalized in 1999 and it would be really nice
to have the class keyword and statically typed variables.

Thanks,
Mark

Simula wrote:
> Does anyone have any knowledge of when version 4 will be
> released? I think that version 3 was finalized in 1999

Edition 4 is now every overdue, in the sense that it was supposed to be
released some time ago. It now seems unlikely that it will ever be
finalised, because Microsoft have already released their version as
JScript.net and are now not motivated to agree a standard that has moved
on, while everyone else don't seem keen to roll back to the version
Microsoft implements (and yes that is 100% speculation).

Not that the release of edition 4 would change anything for many years
as we are still at a point where the wisdom of using some language
features introduced in edition 3 is debatable.

There is also a great deal to be said for never having another version
of ECMAScript. As it is everyone is in a position to move towards one
consistent standard, and as the few bugs in current implementations get
fixed we are very close to having a genuinely reliable bases for the use
of the language. A new language version would call for in half a dozen
new implementations and a whole new set of bugs, differing between
implementations.

> and it would be really nice to have the class keyword

I see no advantage in that. Every useful concept form class-based
languages are demonstrably implementable in ECMAScript.

> and statically typed variables.

Many of the most useful techniques for accommodating differences between
browser object models are facilitated by ECMAScript's loose typing. And
loose typing forces programmers to adopt a more disciplined approach to
perceiving the types they are using, because the language does not make
them obvious.

If you want to program Java or C++ why don't you do that? As it is
ECMAScript is the ideal language for scripting web browsers because it
is dynamic and flexible enough to efficiently accommodate a wide range
of execution environments. Making it more like Java would not help in
that respect at all, as Java is specifically designed for, and lends
itself to, one single and precisely defined execution environment.

Richard.

Simula <> wrote in message news: oups.com...
> Hello All,
>
> it would be really nice to have the class keyword and statically typed variables.

In a compiled language no doubt, but the introduction of a standard will not magically update the range of interpreters
currently in use; making it impractical to exploit such features in code intended for public consumption.
--
Stephen Chalmers

Richard,

As you have pointed out, Javascript is very close to Java or C++ as it
is. Javascript already has classes, it is just that all variables are
public and the function keyword is used to define them. Classes are
for grouping your variables and functions into clear categories and I
think that the class keyword would help clarify the endeavor.

I'm not saying that I wish that the current methods for defining
classes are done away with, just that clearer and more widely known
techniques are added.
I assert the same thing for static typing. I would not wish that
dynamic typing be removed, but static typing would help developers
stamp out logical errors and would potentially result in a speed
increase (if implemented).

I do agree that it would take quite a long time for version 4 to be
implemented within browsers, but I think the additions are worthwhile.
My thought is that the sooner the standard comes out, the sooner it can
be implemented (even if we are talking another 5+ years).

Thanks for the speculation Richard, it helps me understand the
landscape.
Mark

On 28/06/2005 05:00, Simula wrote:

> As you have pointed out, Javascript is very close to Java or C++ as it
> is.

I don't think Richard did anything of the sort. ECMAScript shares syntax
with other languages (not just C++ and Java), and many of the reserved
words from Java, but the similarities more-or-less end there.

> Javascript already has classes,

No, it doesn't.

> it is just that all variables are public

If you create public members, then clearly they will be public. But, as
Richard did point out, ECMAScript is capable of more: both public and
private, static and instance members are feasible. Protected members are
also possible, but they require a lot more effort.

> and the function keyword is used to define them.

The function keyword defines functions. This does include constructor
functions, but these are still just functions, not classes. The only
special thing about them is that they are written with object
construction in mind - you could still call a constructor function like
any other function.

> Classes are for grouping your variables and functions into clear categories

Classes define objects, which in turn allow for abstraction and provide
a way in which a problem can be broken down. Encapsulation groups data
and behaviour.

> and I think that the class keyword would help clarify the endeavor.

I would disagree, in that well-written code will have established
conventions that would make something like a constructor function easily
identifiable. Thorough documentation will also aid understanding of the
code.

> I'm not saying that I wish that the current methods for defining
> classes are done away with, just that clearer and more widely known
> techniques are added.

And you're willing to wait around several years for that?

> I assert the same thing for static typing. I would not wish that
> dynamic typing be removed,

Unless some nasty variant type is added, you can't have both. I would
expect such a type to be horribly misused by many who don't want the
hassle of actually managing their code properly. I've seen VB code where
*everything* is a Variant. Not an Integer or String in sight!

> but static typing would help developers stamp out logical errors

Far from it. Logic errors occur in any sort of code. Static typing just
prevents the change of type at run-time. Only proper testing can prevent
non-syntactic errors.

> and would potentially result in a speed increase (if implemented).

Maybe, but the potential loss of the dynamic properties of ECMAScript
isn't worth that.

> I do agree that it would take quite a long time for version 4 to be
> implemented within browsers, but I think the additions are worthwhile.

It's not how long it would take to be implemented, but how long it would
take for older implementations to fade away. Using the class keyword,
for example, in any current implementations will elicit a syntax error
because class is a future reserved word. Unless a versioning system is
reintroduced, or perhaps a MIME type is registered that existing
implementations won't recognise, you'd have to keep using the same
features from the Third Edition.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Simula wrote:
> Hello All,
>
> Does anyone have any knowledge of when version 4 will be released? I
> think that version 3 was finalized in 1999 and it would be really nice
> to have the class keyword and statically typed variables.
>
> Thanks,
> Mark

There is a page at http://www.mozilla.org/js/language/ that might be of
interest. It has links to older versions and some links to preliminary
versions of 4. The page is not new, but things seem to be moving at a
snail's pace over the last two years.

If you want to see some really drastic changes and extensions in code,
just look at the code that the W3C is working on to replace xhtml 1.1.
The change, so far as the code writing goes, was not drastic from the
1.0 strict to the 1.1 version. However 1.1 does not have frameset and
transitional versions. I have not yet checked to see what the new xhtml
might mean for javascript, if anything.

Simula wrote:
> Richard,
>
> As you have pointed out, Javascript is very close
> to Java or C++ as it is.

I did not point that out, as it is not true.

> Javascript already has classes,

There are not really classes in ECMAScript. All ECMAScript objects are
of the same type, they are just sometimes augmented to have different
properties. This allows them to be perceived as of different types, and
so numerous objects to be of the same distinct 'type', but in reality
they differ only in terms of what has been done to them, and resemble
each other in having had similar things done to them.
The constructor functions are actually a mechanism for arranging to have
numerous objects augmented in similar ways, but not the only means of
doing so by a long way.

Because you can have objects that are all essentially the same (totally
dynamic) type act as instances of the same 'type' and differ from other
'types', allows concepts of classes and instances of classes to be
employed in ECMAScript, even to the extent of designing and describing
code with UML. But it is just a way of thinking about that code, that
may be useful for some applications, and superfluous or inappropriate in
others.

> it is just that all variables are public and the function
> keyword is used to define them. Classes are for grouping your
> variables and functions into clear categories and I
> think that the class keyword would help clarify the endeavor.

It is not difficult to see the grouping of constructor function and
prototype definition as a distinct unit (as common sense would have them
physically adjacent in source code), but if you want more explicit
grouping then you can do that yourself easily enough. Being able to
stick the label 'class' in the source code wouldn't make that much
difference, and the common naming convention of giving constructor
functions initial upper case names should tip readers off when the
concept of 'class' is being implemented, and which code is involved.

> I'm not saying that I wish that the current methods for
> defining classes are done away with, just that clearer
> and more widely known techniques are added.

The problem with continuing to provide the existing mechanisms and then
loading class definitions on top is that it will make the language
considerably more complicated to learn for no significant benefits. Even
those familiar with class-=based languages will need to put work into
understanding how the proposed ECMAScript version differs from their
expectations (in the same way a C++ programmer would have to put effort
into learning how Java differed from their expectations) and because the
original mechanisms remain the novice also has to learn those, in order
to appreciate the circumstances under which they would better suite the
application of the language.

Except, of course, programmers with class-based language experience
would stick to what seemed familiar to them and never go into the areas
of the language that they did not recognise. Javascript already suffers
from that, with many individuals authoring it without any interest in
fully understanding it, and writing code that falls very short of what
it could be as a result.

> I assert the same thing for static typing. I would not wish
> that dynamic typing be removed, but static typing would help
> developers stamp out logical errors and would potentially
> result in a speed increase (if implemented).

And I make the same response for typing. If you retain loose typing
along side strict typing you end up with something that is more
complicated. All of the type safety that strict typing is supposed to
impose is undermined by the loose typing along side it, and the
programmer's discipline of having to always keep track of types
themselves is also relaxed. The result is more likely to be the worst of
both worlds than the best of both.

> I do agree that it would take quite a long time for version
> 4 to be implemented within browsers, but I think the additions
> are worthwhile. My thought is that the sooner the standard
> comes out, the sooner it can be implemented (even if we are
> talking another 5+ years).
<snip>

As I have said, I don't see any benefits in the proposed changes. What I
do see is a (long) transition period where browser script engines are
destabilised just at the point when they are starting to settle down
into being something consistent. Even where apparent back-compatibility
with ECMA 262 3rd edition was achieved by a new 4th edition script
engine the mere fact that it must be a new script engine will mean the
introduction of new bugs, in both its back-compatibility and its new
capabilities. And every other browser would have a different new script
engine with its own bugs.

It seems reasonable that there should be a range of languages for
differing task, and languages better suited to those tasks. ECMAScript,
as it is, is very well suited to scripting web browsers (and other
object models), it is less well suited to being used to write the
business logic for an enterprise, and it would be insanity to attempt to
write an aeroplane fly-by-wire system with it. We have class-based
languages, and employment for them. ECMAScript does not need to be yet
another, inferior, cousin to one of them when it is currently something
valuable in its own right.

Richard.

JRS: In article < .com>
, dated Mon, 27 Jun 2005 18:30:12, seen in news:comp.lang.javascript,
Simula <> posted :

>Does anyone have any knowledge of when version 4 will be released? I
>think that version 3 was finalized in 1999 and it would be really nice
>to have the class keyword and statically typed variables.

One would only be able to use them in safety on an Intranet; it would
take several years before innovations would be safe on the general
Internet/Web.

ISTM that it might be better to have a new language, that being defined
by having a new name. It could include much of the latest javascript,
but would not need to support quaint features such as getYear and months
being 0..11. It could support applicable international standards by
default, with localisation for non-compliant regions.

It would seem wise to state that the first version should only be used
on Intranets (without preventing wider use); the subsequent for-general-
use versions would then have had a design-and-implementation debugging
stage before reaching the wiser public.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Stephen Chalmers wrote:

> Simula <> wrote [...]
>> it would be really nice to have the class keyword and statically
>> typed variables.
>
> In a compiled language no doubt, [...]

Please do note that J(ava)Script/ECMAScript (following: JS) are compiled
languages and they are interpreted ones. They are source code compiled
into bytecode that is interpreted by a Virtual Machine afterwards, much
like it is with Java. The only difference is that compilation with JS
in almost all cases is performed at runtime (just-in-time compilation).


PointedEars

Thomas 'PointedEars' Lahn <> writes:

> Please do note that J(ava)Script/ECMAScript (following: JS) are compiled
> languages and they are interpreted ones.

The only meaningful way to distinguish what I would call compiled and
what I would call interpreted languages, is that compiled languages
are compiled only once, whereas interpreted languages start from the
source code each time they are run.

Any language can be compiled to something else, and any language can
be interpreted by a suitable interpreter, so it's not really the
language that decides, as much as the common use of it. Then again,
some languages are more obviously build for interpretation than
others.

I'd say that JavaScript was designed for interpretation rather than
compilation. This is suggested by a lot of small properties rather
than one specific thing. It's things like the availability of "eval",
allowing handling of source code at run time, and the lack of, e.g.,
types, which are practical when you can check them statically at
compile-time.

So, I'd call JavaScript, and ECMAScript, interpreted languages,
not compiled ones, because they are typically run from source
every time, and are designed to be so.

/L
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'