Doesn't this break encapsulation?

[SteveH]

If you look at the way to make callback functions in the EFS drawing functions:

"@URL=EFS:<function name>"

By doing this instead of simply passing in the actual function name as a parameter for the callback, doesn't this "short circuit" the encapsulation capabilities of the Javascript programming language?

That is, the above has bound me to only having global namespace level callback functions in my scripts instead of being able to embed them within my own objects.

I would appreciate it if a member of the eSignal Development Staff could answer this question.

Thanks.

Re: Doesn't this break encapsulation?

SteveH,

Simply take your object and encapsulated function then create a global namespace variable and use it as a pointer to the function encapsulated in your object. It works.

It doesn't short circuit object encapsulation, JavaScript allows you to make private and exposed methods and parameters when you construct an object. You merely create a variable/function that has global scope from within the object constructor that has access / points to the encapsulated function.

Hope this makes sense.

Steve

Originally posted by SteveH
If you look at the way to make callback functions in the EFS drawing functions:

"@URL=EFS:<function name>"

By doing this instead of simply passing in the actual function name as a parameter for the callback, doesn't this "short circuit" the encapsulation capabilities of the Javascript programming language?

That is, the above has bound me to only having global namespace level callback functions in my scripts instead of being able to embed them within my own objects.

I would appreciate it if a member of the eSignal Development Staff could answer this question.

Thanks.

[SteveH]

Right Steve, that's the workaround hack.

Let me rephrase my "short circuit" comment.

A bad library design decision has forced me to bind all callbacks to the global namespace. The more callbacks which are used, embedded inside objects, the worse this global namespace bookkeeping problem becomes.

But the main problem here is that by using "@URL=EFS:<function name>" in all of the callback drawing functions, the EFS library designers HAVE short-circuited one of the best features of the Javascript programming language...first-class functions.

And this is probably the better question to the eSignal Development Staff:

Why weren't functions directly allowed to be passed as callbacks in the EFS Library? Javascript already provided the capability for you in the form of allowing first-class functions.

P.S.

Steve, you see the bigger design inconsistency in this, don't you? I am allowed to create my own efsLib files, yet, because of this "@URL=EFS:<function name>"...thing...any libraries I use, mine or someone elses, with code available or not, they are no longer self-contained.

The user of a library should not have to know how to dig into that library to reach an embedded callback and the designer of the library should not have to go to the global namespace to manage its own callbacks.

[eSignal_JasonK]

Hello SteveH,

Please put together a simple example that illustrates this problem and what you are trying to accomplish. We'll take a closer look at this issue with the developers.

Thanks,

[SteveH]

[For the posts I'm about to make, I apologize in advance for any formatting distortions in the EFS files posted. I created them with the VIM text editor with a tab setting of 2]

Jason,

This is a the simple test you asked for based on my previous posts in this thread.

It clearly shows how the "@URL=EFS:<function name>" syntax in the drawing function callbacks has bound all callbacks to the Javascript global namespace. Currently, the programming hack to get around this is to point a global variable to the actual function which needs to be called embedded inside the SayHello object.

Callbacks could and should be able to be completely self-contained within objects or efsLibs without the global namespace ever having to be aware of which functions are being called within them as text buttons are pressed on the chart.

When you run this code, you also going to see another problem and this is a second question to the eSignal Development Staff:

Why do you make calls to 2 callbacks if I press the mouse in a text button and NOT give me the option to mask out the call to the global one (i.e. onLButtonDown() in this example) ?

I really want a good answer for this one, not only because it's a re-entrancy problem but also because I have written 1000's of lines of EFS code which use a lot of text buttons on 1 chart and I have never needed the global mouse event function (onLButtonDown) to do something in addition to the callback taking care of the button which was pressed. I have 100% of the time had to mask this event off (i.e., completely ignore it).

I think it is highly reasonable to have an option for a text button to mask off the global mouse event so it doesn't get called when the text button is pressed. The EFS code produced will look so much cleaner and concise if you add this masking option.

The current hack to mask off the global mouse event is, again, polluting the global namespace and requiring Javascript objects and efsLibs to have to know what the name of the global boolean variable is to mask the event. [In the next post's example case, it's the isBtnDown variable]

[See my post above for example code which adds to simple_test.efs to mask off the global mouse callback]

[SteveH]

This example adds on to the simple_test.efs script posted below.

I only need the callback from the text button to service the event and I want to throw away the global mouse event, onLButtonDown().

When I setup the call for the drawing function along with its callback, I should be able to specify that I want that global event not to be called.

See the next post for proposed solutions for the 2 big problems I see with the current EFS callback design, that is:

1. Don't bind callback functions to the global namespace.

2. Add the ability to mask off the global mouse down buttons from being called at the time the related drawing function is called.

There's a third thing to think about in any future designs and that is:

Why not just add another parameter to the callback for the text buttons which lets us know whether the mouse button event was up or down? If I could do that and I can mask off the global event calls (OnLButtonDown, OnLButtonUp, etc.), then ALL mouse events could be localized to the Javascript object or within the efsLib from which they originated.

[SteveH]

Obviously, the attached script, not_implemented.efs, is not going to run so don't bother loading it into a chart. ;-)

I suggest these types of solutions because they are 100% backward compatible with code which has already been written and they won't introduce any new functions into the EFS library.

To address the global namespace binding problem with the current "@URL=EFS:<function name>" callback mechanism, all that's really
needed is to extend that syntax and functionality to allow any valid function reference to be bound to the callback. This would include allowing "this.<function name>" references and multiple dot-based function names.

[Hey, you guys broke Javascript's wonderful first-class function capability by putting that callback function reference into a string form so the least you can do is "un-break it" by parsing it more thoroughly and hunt down any function references behind-the-scenes which are valid to place in that string.]

To address the problem of giving the library user a way of masking off the global mouse down and up events in a drawing function and give an idea of how to implement it, you see a Text.NOGLOBALDOWN and Text.NOGLOBALUP option in the masking items for the drawText function. In the example provided, if you pressed the text button, you would never have the global onLButtonDown() event called or the onLButtonUp() event called. They've been masked off. Of course, this masking is on a per-text button basis.

In not_implemented.efs, I urge everyone to take a long hard look at that drawTextAbsolute() function.

It attempts to solve 3 problems:

1. Any accessible callback function can be called, not just ones from the global namespace.

2. All mouse button events (UP and DOWN) can be captured and localized to the specified callback function.

3. Either the onLButtonDown() or onLButtonUp() or both global events can be masked off so they're not called.

The examples provided in my last 3 posts are simplistic. But as coding becomes more complex, the fixes I've suggested will hold up very well and you'll appreciate the simplicity in that vs. the complexity which grows as more and more text button callbacks are added in the EFS Library's current state.