Why is there javascript peer, can it not just merged with the normal object. Because the javascript code of sys also do not have peer objects.

Probably there is a good reason for it, but I do not see why.

I assume you mean JavaScript FFI - yes it would be cool to have - but haven't really given it much thought at all yet.

Ok I now have removed the peer object and self in the peer functions.

For the constructor I added Peer after the name, since there is the fan constructor and the constructor code in javascript. So in the js code the constructor looks like

fan.svgpane.SvgPane.prototype.$ctorPeer = function(self)
{
  //do js init for object
}

If a function is defined native no js code is generated it must be completed by the peer.js file.

You could also remove the name Peer in the filenames, it would be nicer.

I tested it with my own application, but does not use all component, so there could be a few broken parts. Since i had do to a carefull find and replace operation over all the js files of the dom and fwt pod. In the sys pod js there is only a minor change in the field.js file. Concurrent pod is not affected since the classes them self where completely native.

I think by doing so also fixed a few other bugs related to peer system, since it is now removed.

It is quiet large change set, is there somewhere a possibility to push the change sets, i created a mercurial branch for it on my own machine.

I believe the native peer design has been pretty well vetted across all 3 platforms. What kind of issues are you seeing?

In javascript there is a peer object for each object created. Since there is no need for it did I remove it and it seems to give no problems. The peer object is something extra, which is not needed, so that is why I removed it. The sys and concurrent classes do also not have a peer object in there javascripts objects.

Peers are only created when native slots are used - refer to the Natives chapter under docLang. Sys classes are a special bootstrap case, so they are fully implemented in the platform language.

Yes I know, but I changed the system in such a way it no longer creates this peer objects it just generates no code for the native function, because they are given in the peer functions. When the Peer.js code is added the class is complete. I changed all the files of the fwt and dom pods. Example

fan.fwt.WidgetPeer.prototype.relayout = function(self)
{
  // short-circuit if not mounted
  if (this.elem == null) return;

  this.sync(self);
  if (self.onLayout) self.onLayout();

  var kids = self.m_kids;
  for (var i=0; i<kids.size(); i++)
  {
    var kid = kids.get(i);
    kid.peer.relayout(kid);
  }
  return self;
}

has now become

fan.fwt.Widget.prototype.relayout = function()
{
  // short-circuit if not mounted
  if (this.elem == null) return;

  this.sync();
  if (this.onLayout) this.onLayout();

  var kids = this.m_kids;
  for (var i=0; i<kids.size(); i++)
  {
    var kid = kids.get(i);
    kid.relayout(kid);
  }

  return this;
}

Oh yes - that's possible to do - tho that's a pretty huge change. Not only would we need to fix the existing peer code, but a lot of code probably has/should get refactored since the slot namespaces will get merged. The existing design pattern has been you can mostly do whatever you want in your peer class since it won't effect what's exposed via the Fantom type instance, which of course would no longer be true.

This would mostly be a cosmetic change tho, and would then be a bit inconsistent w/ Java and C#, but would be a bit cleaner. I don't anticipate any problems, tho on the fence if it's worth doing. Anyone else have an opinion on whether or not we pursue this?

One thing that is quite different b/w Java/C# and JavaScript is that in Java/C# classes are closed so we have to delegate peers to another class. In JavaScript we don't have these restrictions so there is definitely the possibility of creating a more elegant "native" model by just inserting the proper implementations without a peer delegate.

The only downside I see is that if the peer has its own complicated namespace of fields and methods, that you would be required to mangle the names to keep the Fantom namespace clean to avoid naming collisions. But I suspect in most cases that this wouldn't be a real issue.

So changing JavaScript to not use peers would potentially remove an extra object and level of indirection. In FWT this probably doesn't matter too much, but in some classes this might really important.

There is also the issue that we already have a peer design in place. So I think any proposed change would require near universal community support before we could consider a breaking change of that magnitude.

I agree,

I must admit that for people who already created a lot of js code, have to do quiet a lot of find and replace, in the same way as I did with the fwt package. But it is a rather straight forward process in doing so.

I do not see the problem of namespaces, since the peer code is also written by the person who writes the fantom code and knows which names are used. I must admit there is no compiler checking for any possible conflicts.