Re: [Dynapi-Dev] DynAPI X [addCodeToMethod]

[Jordi - IlMaestro - Ministral]

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