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
