Hello Lamee

On 04-Apr-01, you wrote:

>> Think of every Javascript feature known to man. Imagine Voyager
>> having it implemented. That's about the gist of it :)
> 
> Ok, for the sake of (friendly) argument:
> 
> Voyager having implemented the complete JS v1.2 would actually make me very
> happy. Isn't that what standards are for? Implementing it all, so web
> developers using JS can rely on the standard?

Voyager implements certain things right up to the Core Javascript 1.4 docs
from Netscape. Other things it does not. 

Because it is based entirely on objects, which then have properties and
methods, it is simple to get a basic logic system down (so you can do things
like if/then/else/while/do/with/select/case) and then implement the
classes afterwards. There isn't much that V doesn't do on the procedural
side, but things need to be filled in, and events need to be handled on
objects.

Which objects get done first? Well, the ones that people miss the most.
 
>> When it gets implemented is a matter of priorities: crash bugs and

[snip]

>> some scary JS operation when the only place it gets used is in
>> theory and on your homepage :P
> 
> I guess I'm a bit spoiled, being a programmer and all. When I think of a
> programming language like C or C++ or Java, it's hard to imagine it to be
> 'partially implemented' at the client side.

It's easy. Look at StormC++ - it still doesn't implement STL :)

> JavaScript being an interpreted language does allow you not to implement
> certain parts of it

Being interpreted has nothing to do with it, you could compile Javascript and
still miss out a good deal of functionality.

> see why a complete implementation of JavaScript should be impossible.

It isn't. It's just time consuming to get EVERY little piece of functionality
down. The goal is to implement everything as well as possible - for the
most part to do everything that Internet Explorer does within reason.

That also means stuff that Netscape does that IE doesn't like Javascript
entities, btw.

The trick is that

> does not do. I don't know if this is too simplistic a view on things, but if
> AWeb can do a complete v1.1 JS implementation, I do not consider similar
> functionality to be as remotely possible as you seem to imply in your first
> paragraph.

It is possible, the architecture of V makes it easy to add a lot of things wrt
the DOM (so pick an HTML element - and then simply add the Javascript
functionality to it as per the docs)

As I say though, it takes time to implement things like this. I've got the Js
docs in front of me, and I keep making testcases that stress objects and
functionality so that Olli can make them work as they should. But when
there are other bugs to fix, and most sites don't need a particular feature,
then it's easy to get it down half-way and move to something with a
higher priority.

I'm sure you'd rather have V stop crashing every 20 minutes than be able
to write to an Option object. I'm sure that the ability to use Javascript
entities is less of a royal pain than the way 

<SCRIPT>
  var foo = 10; 
/* </script>  */
  var bar = 11;
</SCRIPT>

will prematurely end the script, never set "bar" to 11, and even print
everything after the angle bracket ( */ var bar = 11; </script>) even
though it's in a comment. It's bugs like this that happen on real sites
(there is some ad banner code somewhere that does this) that get
fixed before anyone adds huge amounts of new functionality somewhere.
 
>> It's hard to test out features when all you have is your own rolled
>> code half-cut-and-paste from the manuals, and an inkling of why
>> V doesn't do it yet. Real sites make a lot of difference.
> 
> Comparing my own rolled code half-cut-and-paste from the manuals vs. real
> sites ... I believe a bit of extra contextual information might be in order
> here:

Basically all I'm saying is that following specifications is all well and good,
but it's hard to make sure you did it right unless there are real world uses
of the stuff in the specs.

Sometimes it's better not to do something at all, than do it wrong and end
up rewriting it later. 

> - http://www.bobs-teleshop.nl/Main.html
> - http://www.bobs-teleshop.nl/Bestellijst.html

I'll take a look at those. Can you describe EXACTLY what you're doing in
these pages? What JS do you use that doesn't work?

> Now, getting back to the feature I mentioned, the JavaScript entities: This
> feature is clearly described in Netscape's own JavaScript documentation, and
> Navigator as well as AWeb support it, and it is also described as a standard
> way of using JavaScript in HTML pages in the O'Reilly JavaScript book. Which
> is why I thought I might 'pop the question to you'.

Yes. And if you find a site that uses it in the real world, it'll give everyone
a bigger incentive to implement it. It WILL be in there, somewhere along the
line. Not right away: Olli isn't going to drop the bugs he has to fix now
because of crash issues or huge layout errors now to fill in some functionality
that nobody uses.
 
> As a web developer, I see no point in implementing any features that the
> major browsers on the bigger platforms do not support, because I won't be
> using them anyway.

But they will be in there. I'm just saying have patience with it, because they
aren't as important as OTHER parts of Javascript, because they aren't in use
by IE, and therefore not in use by a great deal of sites.

The implementation of JS in V is by the documentation: when we want to
see how something works, we all take a peek at the documentation and
then make testcases from them, and then see if we can get V to run through
them as expected. Once they do, that's fine. Bugs can be tracked when we
find odd, unexpected ways of using an object or construct that obviously
works in IE or Netscape.

But there are other parts of JS that are more important :)
But it will be done. Just after some other stuff gets done ;)

Is that okay? :)

Thanks
-- 
Matt Sealey <[EMAIL PROTECTED]>
Website http://www.kittycat.co.uk

_____________________________________________________________________
Voyager Mailing List - http://v3.vapor.com/
Voyager FAQ....: http://faq.vapor.com/voyager/
Listserver Help: mailto:[EMAIL PROTECTED]?Subject=HELP
Unsubscribe....: mailto:[EMAIL PROTECTED]?Subject=UNSUBSCRIBE

Reply via email to