What do you mean appending conflicting code?
DynDocument.prototype.xxxx = DynDocument.prototype.y
DynDocument.prototype.y = function() {
this.xxxx()
somestuff = 1
}
This can be achieved by rewriting the addCodeToMethod.
I dont see the problem with this.
Rob
----- Original Message -----
From: "Doug Melvin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 16, 2001 4:37 PM
Subject: Re: [Dynapi-Dev] DynAPI X [addCodeToMethod]
> that's a very good idea, but it still leaves us open to 'appending'
> conflicting code
> ----- Original Message -----
> From: "Robert Rainwater" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, March 15, 2001 6:43 PM
> Subject: Re: [Dynapi-Dev] DynAPI X [addCodeToMethod]
>
>
> > Why not just rewrite the addToMethodCode to do this instead of having to
> do
> > it each time. You can use a counter to have a unique old method name.
> Then
> > create a new function that calls the old method and then eval the new
> > function.
> >
> >
> > ----- Original Message -----
> > From: "Jordi - IlMaestro - Ministral" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, March 13, 2001 6:53 PM
> > Subject: Re: [Dynapi-Dev] DynAPI X [addCodeToMethod]
> >
> >
> > > Ok.
> > >
> > > Instead of going into a programming techniques discussion I'll look at
> > this from
> > > another point of view: this project is for use of a broad community of
> > > developers. It is obvious that this method does not and will not make
> > users feel
> > > comfortable, and will always look at it with a raised eyebrow as if it
> > could
> > > come to life and bite them anytime. This is not the first feedback I
> > receive on
> > > this matter.
> > >
> > > Therefore I prefer to rewrite it as people suggests. There's no point
in
> > going
> > > stubborn when we can achieve the same in a way we all agreee with.
> > >
> > > Sight, there's no room for creative programming anymore.... snifff....
> At
> > least
> > > I've caused one of world wide dhtml masters to step in, wow that made
it
> > worth
> > > the work. :)
> > >
> > > I can't help but feeling atracted by the kind of chaos that one could
> > create
> > > when having code rewrite itself.... sounds pretty organic... not for
the
> > DynAPI
> > > but it must have some use.
> > >
> > >
> > > Erik Arvidsson wrote:
> > >
> > > > I usually try to stay out of the discussions about the DynAPI but
this
> > time
> > > > I could not...
> > > >
> > > > Just like some people have mentioned, the addCodeToMethod is a
really
> > bad
> > > > idea. A better idea is ofcourse to redefine the method. The
following
> > line
> > > > could be replaced by a much safer way.
> > > >
> > > >
> >
>
Methods.addCodeToMethod("DynDocument.prototype.addEventListener","if(this.ha
> > > > sEventListeners) this.captureKeyEvents()",true);
> > > >
> > > > DynDocument.prototype._beforeKeyEvent_addEventListener =
> > > > DynDocument.prototype.addEventListener;
> > > > DynDocument.prototype.addEventListener = function (oListener) {
> > > > this._beforeKeyEvent_addEventListener(oListener);
> > > > if (this.hasEventListeners)
> > > > this.captureKeyEvents();
> > > > };
> > > >
> > > > This code is much safer and smaller (if a general funtion is created
> to
> > make
> > > > it easier to reuse).
> > > >
> > > > Using string manipulation is not a good idea because not only can
one
> > not
> > > > guarantie that the toString() method returns something meaningful
but
> it
> > > > also destroys the variable scope for the old function. I'll show a
> > simple
> > > > example showing what I mean about the scope (not a typical case but
> > simple):
> > > >
> > > > function createFunction() {
> > > > var x = 5;
> > > > return function () {
> > > > return x;
> > > > };
> > > > }
> > > >
> > > > foo.method = createFunction();
> > > >
> > > > if you then later reevaluate the string for the function in the
> > following
> > > > context you you changed the semantics for the function.
> > > >
> > > > var x = "It even changes type";
> > > > Methods.addCodeToMethod("foo.method","alert(x);",false);
> > > >
> > > > I hope this is enough for you to rethink your decission.
> > > >
> > > > erik arvidsson
> > > > http://webfx.nu
> > > >
> > > > ----- Original Message -----
> > > > From: "Jordi - IlMaestro - Ministral" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Tuesday, March 13, 2001 8:09 AM
> > > > Subject: Re: [Dynapi-Dev] DynAPI X
> > > >
> > > > > Well yes if any of my computer engineering teachers could see that
> > code,
> > > > they'd
> > > > > throw me through the window. If I had come up with a better idea,
> then
> > I
> > > > would have
> > > > > chosen that one. The fact here was that we needed to add
> > functionalities
> > > > to certain
> > > > > pieces of code depending on what was loaded. However, it is simply
> > > > intended to add
> > > > > lines of code ( typically function calls ) to an already defined
> > method. I
> > > > don't
> > > > > provide this as a generic coding practice, nor expect people to
> start
> > > > modifying ifs
> > > > > statements on the fly depending on what browser you're using. Then
> it
> > will
> > > > become a
> > > > > nightmare.
> > > > >
> > > > > This function, being as dangerous as it is, if used with common
> sense
> > > > allows to get
> > > > > rid of all those anoying additons that check for a module being
> > loaded. It
> > > > is not
> > > > > intended to be used that often. So far only when mouse event
> capturing
> > > > must be
> > > > > inserted into layer creation and little more. Notice that the
DynAPI
> > > > object
> > > > > provides methods for attaching code into the onload event, which
is
> > what
> > > > extensions
> > > > > such as inline will use. I could have had extensions modify the
> > onload,
> > > > onunload
> > > > > and onresize via the addCode method(), but seeing that it would be
a
> > > > common thing
> > > > > to do, I prefered to provide anot-so-dangerous method, while
leaving
> > the
> > > > dangerous
> > > > > code reserved for 'internal usage'.
> > > > >
> > > > > Lesson: try not to use Methods.addCodeToMethod() as a common
> practice.
> > > > >
> > > > > Daniel Aborg wrote:
> > > > >
> > > > > > Jordi - IlMaestro - Ministral wrote:
> > > > > > > Fift: i have included a generic method that allows to add
lines
> of
> > > > code to
> > > > > > > already defined methods. So if you look at dynlayer.js and you
> > can't
> > > > see any
> > > > > > > eventcapturing code, don't be puzzled. If you open mouse.js (
> > where
> > > > the
> > > > > > > mouseevents are now ) you will see a call to
> > > > > > > addCode("createLayer","this.captureMouseEvents()"). This way
of
> > > > working makes
> > > > > > > it possible for optional files ( mousevents ) to add stuff to
> > already
> > > > defined
> > > > > > > methods, without having to have ugly if(mouseEvent)
> > > > this.captureMouseEvents()
> > > > > > > lines and such. Besides, this way we have eradicated
> > crossreferences
> > > > between
> > > > > > > files.
> > > > > >
> > > > > > Having given this a few minutes of thought, this is something
> which
> > > > > > scares me. Having the possibility of your function being
modified
> by
> > any
> > > > > > other package or extension is a horrible thought, because it
means
> > you
> > > > > > have no way of telling in what ways your function might change
> > > > > > dynamically during loadup. It seems like a typical opening for
> > > > > > maintainance nightmare, introducing the possibility for bugs
> caused
> > by
> > > > > > other packages which aren't synchronised with your function.
> Imagine
> > > > > > having a function which is possibly modified by 17 other
packages
> in
> > > > > > unpredictable ways during loadup depending on what packages you
> > load,
> > > > > > without having any knowledge of /whether/ your function will be
> > modified
> > > > > > by anyone in the future, /how/ it will be modified, /when/ it
will
> > be
> > > > > > modified, and so on. You could break any code anywhere just by
> doing
> > a
> > > > > > simple change/bugfix to your function without ever having any
idea
> > of
> > > > > > what you could break, simply cause you can't know who will
modify
> > your
> > > > > > function in the future, how it will be modified, and so on. It
> > totally
> > > > > > removes encapsulation borders around function implementations.
> > Shiver!
> > > > > >
> > > > > > I might be overly cynical, although it seems to me that this
would
> > call
> > > > > > for a system for how you can modify existing functions so the
> > functions
> > > > > > know how they might be modified and can take that into account,
> and
> > > > > > perhaps additionally for some way of saying that a function
can't
> be
> > > > > > modified. Basically, some kind of control framework to let the
> > modified
> > > > > > functions control how and where it's modified. I assume you're
> doing
> > > > > > this with string manipulation, so it shouldn't be hard to handle
> > that.
> > > > > >
> > > > > > Anyway, just my thoughts on the matter. I might have gotten a
bit
> > > > > > carried away. :)
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Daniel
> > > > > >
> > > > > > --
> > > > > > Daniel Aborg <[EMAIL PROTECTED]>
> > > > > > T: 0207 445 447 M: 07720 29 44 40
> > > > > >
> > > > > > _______________________________________________
> > > > > > Dynapi-Dev mailing list
> > > > > > [EMAIL PROTECTED]
> > > > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
