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
