[Laszlo-dev] The meaning of <handler> and <method> in <library>
P T Withington
ptw at openlaszlo.org
Thu Jun 21 19:30:45 PDT 2007
On 2007-06-21, at 11:23 EDT, David Temkin wrote:
> [moving thread to laszlo-dev]
>
> I think what I said on this issue may have gotten lost in translation.
>
> I'm not sure it's a bad thing from a language point of view that
> <library> allows you to add methods and handers to the canvas, and
> I certainly don't think it "breaks the XML structure" -- no more
> than <state> breaks it. Given how <library> is defined, I would
> expect it to put methods/handlers/whatever into its parent. That's
> how we defined it.
>
>>>>> it totally breaks my mental
>>>>> model which was that everything declared in a library was exactly
>>>>> like declaring directly in the canvas tag. I'll bet other
>>>>> developers
>>>>> have this mental model also. Since the coding pattern is
>>>>> often that
>>>>> you code merrily along in a <canvas> tag than re- factor into
>>>>> libary
>>>>> files by simply cutting parts into various files.
>
> I agree with this viewpoint. The model implied by <library>/
> <include> is essentially one of textual inclusion with a little bit
> of add-on smarts.
Initially they were just a textual inclusion. Then we asked the
compiler not to include them more than once. Then we asked the
compiler to auto-include some of the libraries when it saw a tag that
was defined in the library; but to not get confused if the programmer
also explicitly included the library. Or a library the programmer
included included that library.
Then we asked for libraries to be separate compilation units.We get
by with this in Dynamic libraries, because we require you to compile
your entire program at once, even though the library load will be
deferred. With binary libraries we have asked that you be able to
compile the library without knowing where it might be included. We
can still squeak by here because we still require that you compile
your entire program at once.
I can see what is coming: a requirement to compile a library
separately and then dynamically load it at run time.
If we do that, and take the 'intuitive' definition that top-level
forms in a library are children of whatever node contains the
include, we lose the ability to take advantage of the key
optimization in Flash 9 -- sealing. We have to leave any node that
contains an include dynamic, because it may be amended at runtime by
loading a library whose contents are unknown.
I think the sealing optimization is more valuable than being able to
declare canvas methods in a library. (Handlers are less of an
issue, because we already have a syntax for attaching a handler to
another node.) Do we want to give up sealing? How important is it
that libraries be able to add methods to the canvas? In the cases I
have seen so far, the library could just as well define a global
function in a script tag.
> That isn't to say that this could be changed if there's a very good
> reason to do so (simpler implementation, more room for
> optimization). But I do think the construct as now defined, with
> the implied behavior of attaching its child elements to the element
> that embeds the <library> element (canvas), makes sense. Exceptions
> to this reduce learnability.
>
> - D.
>
>> On Jun 20, 2007, at 8:41 PM, Sarah Allen wrote:
>>
>>> including internal-dev, rather than the list of developers who
>>> happen to
>>> listen to P4 reviews... (new folks, please read Tucker's note below
>>> first, and only if you typically definite canvas methods or
>>> events in
>>> libraries)
>>>
>>> The heart of the question, is what does the <library> tag mean?
>>> It is
>>> not a node, like every other tag in LZX, and gets magically compiled
>>> away. Everything else that is inside the library tag is
>>> conceptually
>>> under the <canvas> tag, hence the confusion.
>>>
>>> My question regarding OL4 was that if this is a side-effect of the
>>> compiler in 3.4, might that have changed in OL4 when there was a
>>> substantial refactor of the whole system? If it is working in
>>> OL4, it
>>> is pretty dangerous and weird to support something that you all
>>> believe
>>> is inappropriate and plan to break in the future (although I
>>> wouldn't
>>> recommend breaking it right now just for the sake of language
>>> purity.)
>>>
>>> Sarah
>>>
>>> p.s. if you all think its a really bad thing to declare methods and
>>> handlers in libraries, we can stop doing it. I just want to be
>>> clear on
>>> what works and what doesn't and why.
>>>
>>> On Wed, Jun 20, 2007 at 8:15 PM, P T Withington wrote:
>>>
>>>> [Adding Platform-Team, perhaps our chief language architect
>>>> would like
>>>> to weigh in on this. Oh, wait, he quit. Bueller? Anybody?]
>>>>
>>>> On 2007-06-20, at 17:59 EDT, Sarah Allen wrote:
>>>>
>>>>> so... for the record:
>>>>>
>>>>> You can, in the main file that starts with <canvas>, have handlers
>>>>> and methods
>>>>> You cannot, in a library, define handlers and methods, but you
>>>>> could
>>>>> declare
>>>>> <method event="oninit" reference="canvas">
>>>>> (although perhaps this isn't the right syntax, because I thought
>>>>> Elliot mentioned to me that events were deprecated in OL4)
>>>>
>>>> The new syntax is:
>>>>
>>>> <handler name="oninit">
>>>>
>>>> If this tag appears as an immediate child of the canvas, the
>>>> reference
>>>> defaults to the canvas (it defaults to the parent of the handler
>>>> tag).
>>>> If you want to write a handler in some tag other than the canvas
>>>> but
>>>> want it to handle the canvas's `oninit` event, you need to
>>>> explicitly
>>>> supply the reference:
>>>>
>>>> <handler name="oninit" reference="canvas">
>>>>
>>>> That's my understanding of the language. Clearly we define the
>>>> language and if we want a different definition we can make it so.
>>>> But, my opinion from both an XML point of view and from the
>>>> compiler
>>>> implementor point of view is that it would be a bad idea to say
>>>> `handler` in a `library` implicitly refers to the canvas.
>>>>
>>>> A separate question is whether you should be able to have a handler
>>>> tag directly inside a library or not. Right now the compiler only
>>>> expects to have (subclasses of) node at the top level, e.g.,
>>>> classes
>>>> or instances and scripts.
>>>>
>>>>> and in a library, I could define
>>>>> <script>
>>>>> canvas.myMethod = function ...
>>>>> </script>
>>>>
>>>> This is true, but again with my language/compiler hat on we really
>>>> don't want to support that. If you want to support this in
>>>> Flash 9,
>>>> it will mean we cannot take advantage of their fast class
>>>> implementation. To have the ability to add methods to a class
>>>> at run
>>>> time, you have to declare the class to be dynamic, which makes
>>>> it run
>>>> in slow mode.
>>>>
>>>> This is what I was trying to get at below with my discussion of
>>>> 'compilation units'.
>>>>
>>>>> is this true?
>>>>
>>>> Yes. With the caveats I have mentioned.
>>>>
>>>>> is this only a limitation with binary libraries?
>>>>
>>>> It is a limitation of libraries. As David said, it was really
>>>> only an
>>>> accident that it worked in libraries. If you made your library a
>>>> dynamic library it would not work. And it does not work in a
>>>> binary
>>>> library. It could be made to work. Making it work will limit the
>>>> optimizations we can make in the future.
>>>>
>>>>> is this also a limitation for OL4?
>>>>
>>>> It has nothing to do with OL3 vs. 4. It has to do with our
>>>> libraries
>>>> becoming real libraries (being treated as separate compilation
>>>> units)
>>>> rather than straight includes.
>>>>
>>>>> We can probably live with this, but it totally breaks my mental
>>>>> model which was that everything declared in a library was exactly
>>>>> like declaring directly in the canvas tag. I'll bet other
>>>>> developers
>>>>> have this mental model also. Since the coding pattern is
>>>>> often that
>>>>> you code merrily along in a <canvas> tag than re- factor into
>>>>> libary
>>>>> files by simply cutting parts into various files. The problem is
>>>>> made worse by the fact that it happens to work just fine in LZX
>>>>> (3.4) today.
>>>>
>>>> If libraries were straight textual includes, I could see that. But
>>>> they aren't (despite using the tag `include` to refer to them: it
>>>> would have been better if we used the tag `require` because that is
>>>> what the compiler really does -- it keeps track of whether or
>>>> not it
>>>> has already loaded a library and only loads it once).
>>>>
>>>>> Confused,
>>>>> Sarah
>>>>>
>>>>> On Wed, Jun 20, 2007 at 2:23 PM, P T Withington wrote:
>>>>>
>>>>>> I thought what David was getting at was that syntactically, it
>>>>>> looks like you are trying to add the methods/handlers to the
>>>>>> library, not the canvas. It breaks our nice XML language model.
>>>>>>
>>>>>> We allow you to put methods and handlers on the canvas, but they
>>>>>> should appear in the canvas tag, not in some inner tag (like
>>>>>> library).
>>>>>>
>>>>>> From the compiler-guy-who-has-to-implement-this point of view, we
>>>>>> treat a library as our unit of compilation, and it is generally
>>>>>> considered a bad thing in language design to permit one
>>>>>> compilation
>>>>>> unit to diddle with the internals of another. (It's
>>>>>> permitted in
>>>>>> C++, which everyone now agrees is a mistake, because it means
>>>>>> technically only the linker can optimize C++.)
>>>>>>
>>>>>> As I explained to Eliot, you are allowed in our language to add
>>>>>> handlers for events on other objects, so you can add a handler to
>>>>>> the canvas, but you'll need to tell the compiler the `reference`
>>>>>> for the handler (and put the handler declaration in a place that
>>>>>> allows it).
>>>>>>
>>>>>> In any case, I didn't do anything about this issue, because
>>>>>> of what
>>>>>> David said, and because we worked around the places where it was
>>>>>> used (unfortunately, I don't recall the details).
>>>>>>
>>>>>> On 2007-06-20, at 16:40 EDT, Sarah Allen wrote:
>>>>>>
>>>>>>> The case Elliot ran into may not be right, but I do believe
>>>>>>> that
>>>>>>> it is a feature not a bug that we can define a method on the
>>>>>>> canvas. I replied to the thread below with:
>>>>>>>
>>>>>>> what do you mean by side-effect? the lzo compilation bug? or
>>>>>>> the
>>>>>>> fact that we can declare methods on the canvas? (if the
>>>>>>> latter,
>>>>>>> you may have never planned it that way, but we have been
>>>>>>> expecting
>>>>>>> and relying on that behavior for years, and if you want I
>>>>>>> can let
>>>>>>> you know why I think it is a good thing)
>>>>>>>
>>>>>>> and I thought you had gone ahead and fixed binary libraries so
>>>>>>> that the behavior was supported. I sure hope it is supported in
>>>>>>> Legals, even if it was not a feature you ever intended to
>>>>>>> support
>>>>>>> at the beginning of time. Certainly defining an onint on the
>>>>>>> canvas is required...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 20, 2007 at 9:20 AM, P T Withington wrote:
>>>>>>>
>>>>>>>> Here's my understanding (elaborating on this message from David
>>>>>>>>
>>>>>>>>> On 2007-03-07, at 10:48 EST, David Temkin wrote:
>>>>>>>>>> That seems like a side-effect or bug to me. I would not
>>>>>>>>>> expect
>>>>>>>>>> it to work that way.
>>>>>>>>>>
>>>>>>>>>> On Mar 7, 2007, at 6:03 AM, Sarah Allen wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Here's an example of a library that defines a method on the
>>>>>>>>>>> canvas:
>>>>>>>>>>>
>>>>>>>>>>> <library>
>>>>>>>>>>> <method name="foo"/>
>>>>>>>>>>> </library>
>>>>>>>>
>>>>>>>> ):
>>>>>>>>
>>>>>>>> It is an accident of the implementation of the compiler
>>>>>>>> that top-
>>>>>>>> level <method> (<handler>, etc.) tags in a <library> have been
>>>>>>>> getting attached to the canvas. This should be an error,
>>>>>>>> because
>>>>>>>> libraries are not nodes, so don't have methods (handlers,
>>>>>>>> etc.).
>>>>>>>> To change that would mean an architectural change to the
>>>>>>>> language. The bug here is that the compiler (binary or normal)
>>>>>>>> does not complain when it stumbles across these illegal
>>>>>>>> tags in a
>>>>>>>> library.
>>>>>>>>
>>>>>>>> In the particular case that Eliot has run across, it seems what
>>>>>>>> you are trying to do is wait until you know that the dialog
>>>>>>>> handler class is defined before you tell the dialog manager
>>>>>>>> about
>>>>>>>> it. This can easily be handled by a <script> tag following
>>>>>>>> the
>>>>>>>> class definition. Script tags are defined to be evaluated in
>>>>>>>> lexical order.
>>>>>>>>
>>>>>>>> On 2007-06-20, at 11:30 EDT, Sarah Allen wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> really? I thought Tucker had made it so there could be
>>>>>>>>> methods
>>>>>>>>> on the canvas? I certainly hope we can declare a canvas
>>>>>>>>> "oninit"
>>>>>>>>> handler...
>>>>>>>>>
>>>>>>>>> On Wed, Jun 20, 2007 at 7:50 AM, Elliot Winard wrote:
>>>>>>>>>
>>>>>>>>>> My bad.
>>>>>>>>>>
>>>>>>>>>> The problem here was the way the dialogs registered
>>>>>>>>>> themselves
>>>>>>>>>> with the gDialogManager.
>>>>>>>>>> Dialogs are not instantiated until they are needed and
>>>>>>>>>> are then
>>>>>>>>>> reused.
>>>>>>>>>> The LZX files included oninit handlers that registered
>>>>>>>>>> themselves for canvas oninit events. Binary libraries
>>>>>>>>>> can have
>>>>>>>>>> class definitions and instances but can not include handlers
>>>>>>>>>> outside of class definitions and instances.
>>>>>>>>>>
>>>>>>>>>> The fix was to hard-code the names of default classes to use
>>>>>>>>>> for Confirm and Alert dialogs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 20, 2007 at 9:43 AM, Sarah Allen wrote:
>>>>>>>>>>
>>>>>>>>>>> In a changeset like this it would be good to note the spirit
>>>>>>>>>>> of the bug fix. What was the underlying problem and how was
>>>>>>>>>>> it addressed? I know I could look at the diffs, but a
>>>>>>>>>>> summary
>>>>>>>>>>> would be nice.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Sarah
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------- Begin forwarded message --------
>>>>>>>>>>> Subject: PERFORCE change 51366 for review
>>>>>>>>>>> Date: 6/19/2007 4:10:33 PM
>>>>>>>>>>> From: Elliot Winard <ewinard at laszlosystems.com>
>>>>>>>>>>> To: Bret Simister <bsimister at laszlosystems.com>, Chris
>>>>>>>>>>> Pettitt
>>>>>>>>>>> <cpettitt at laszlosystems.com>, Dave Nault
>>>>>>>>>>> <dnault at laszlosystems.com>, Elliot Winard
>>>>>>>>>>> <ewinard at laszlosystems.com>, Scott Evans
>>>>>>>>>>> <gse at laszlosystems.com>, John Sundman
>>>>>>>>>>> <jsundman at laszlosystems.com>, lchouanard
>>>>>>>>>>> <lchouanard at laszlosystems.com>, Mark Davis
>>>>>>>>>>> <mdavis at laszlosystems.com>, Pablo Kang
>>>>>>>>>>> <pkang at laszlosystems.com>, qa <qa at laszlosystems.com>, Sarah
>>>>>>>>>>> Allen <sallen at laszlosystems.com>, Yossie Silverman
>>>>>>>>>>> <yossie at laszlosystems.com>, David Temkin
>>>>>>>>>>> <temkin at laszlosystems.com>
>>>>>>>>>>>
>>>>>>>>>>> Change 51366 by ewinard at EWINARD-T60-3.4 on 2007/06/19
>>>>>>>>>>> 16:06:02
>>>>>>>>>>>
>>>>>>>>>>> BUG FIXED::EM-1685::Cannot delete Folders in http://emma:
>>>>>>>>>>> 8080/ diamond-lzmail-sql-dist-lzmail-silver-latest/ 1241
>>>>>>>>>>> BUG FIXED::EM-1684::Unable to delete the folder with delete
>>>>>>>>>>> folder button or right click option
>>>>>>>>>>> BUG FIXED::EM-1686::Once enter rich text into the message
>>>>>>>>>>> body, the user will not be able to switch back to the plain
>>>>>>>>>>> text
>>>>>>>>>>> BUG FIXED::EM-1683::Anything with a confirmation pop up
>>>>>>>>>>> fails. All error and warning pop ups are not occurring. in
>>>>>>>>>>> http:// emma: 8080/diamond-lzmail-sql-dist-lzmail-silver-
>>>>>>>>>>> latest/ 1241
>>>>>>>>>>> BUG FIXED::EM-1671::Can not sign out if editing a contact
>>>>>>>>>>> BUG FIXED::EM-1670::Can not sign out if a modified
>>>>>>>>>>> preferences view is open
>>>>>>>>>>> BUG FIXED::EM-1669::Can not log out if you have a compose
>>>>>>>>>>> view open
>>>>>>>>>>> BUG FIXED::EM-1672::Can not sign out while a message is
>>>>>>>>>>> being
>>>>>>>>>>> sent
>>>>>>>>>>> BUG FIXED::EM-1670::Can not sign out if a modified
>>>>>>>>>>> preferences view is open
>>>>>>>>>>> BUG FIXED::EM-1690::Delete contact button cannot be used to
>>>>>>>>>>> remove the selected contact from list.
>>>>>>>>>>> REVIEWER::pablo
>>>>>>>>>>>
>>>>>>>>>>> Affected files ...
>>>>>>>>>>>
>>>>>>>>>>> ... //depot/apps/diamond/client/components/window/dialog/
>>>>>>>>>>> alertdialog.lzx#5 edit
>>>>>>>>>>> ... //depot/apps/diamond/client/components/window/dialog/
>>>>>>>>>>> confirmdialog.lzx#5 edit
>>>>>>>>>>> ... //depot/apps/diamond/client/framework/utils/
>>>>>>>>>>> gdialogman.lzx#10 edit
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---=---===-------
>>>>>>>>>> Elliot Winard
>>>>>>>>>> Sr. Software Engineer
>>>>>>>>>> Laszlo Studios
>>>>>>>>>> ---=---===-------
>>>
>>> _______________________________________
>>>
>>> Internal-Dev mailing list
>>> Internal-Dev at laszlosystems.com
>>> https://hedwig.laszlosystems.com/mailman/listinfo/internal-dev
>>>
>>> To search the dev list: http://lists.laszlosystems.com/intranet/
>>> finddev.cgi
>>
>
More information about the Laszlo-dev
mailing list