Re: [Laszlo-dev] The meaning of and in

[P T Withington]

I'm not saying that we could _never_ take advantage of the  
optimizations.  But, all optimization is a trade-off against  
flexibility -- optimization basically boils down to moving a decision  
from run time to compile time, and as a result, you can't change that  
decision at run time if you want the optimization.

I've always been optimistic that we could 'tighten up' LZX, taking  
away a little bit of flexibility to get optimization, and not impact  
developers too much.  This is probably a good test case.  I don't  
think this is a carefully thought out corner of the language.   
Developers have a mental model of it, and Sarah's group was surprised  
when the implementation strayed from that model.  As the compiler  
writer, I was surprised by the developer's model.  What we need to  
know is "exactly how pervasive is the impact on developers if we take  
away this 'feature'".  AFAICT, there are easy work-arounds in both  
cases.

I'm sure AS programmers get just as surprised when they port from AS2  
to AS3.  They can choose not to convert to using class declarations,  
but then they won't get any optimizations.  If they do convert, they  
surely have to make similar decisions as to whether they need dynamic  
classes or prototype properties.  We have the luxury that most of  
those decisions should be able to be made by the tag compiler, which  
should make the porting process nearly automatic.  There are going to  
be cases where we will have to take some flexibility away from the  
language to make those decisions computable.

Another example:  We currently allow you to override the method  
`construct` when defining a class, which gets a list of the  
attributes of your class and their initial values.  This method is  
actually allowed to modify, add, remove attributes before each  
instance is created.  I don't _think_ anyone actually uses this  
ability.  Clearly we need to take that away if we want to have sealed  
classes.

There may be cases where we have to ask the developer to declare  
their intent for the compiler to make the right decisions.

On 2007-06-22, at 17:57 EDT, David Temkin wrote:

[meant to send to Laszlo-dev]

Well, this is at least a little bit scary. You did say earlier that  
we'd be able to preserve LZX semantics with ECMA4/Flash 9/Tamarin,  
but what you didn't say was that the implication would be that we  
couldn't take advantage of the performance benefits it offers....  
hmm...

On Jun 22, 2007, at 10:27 AM, P T Withington wrote:

On 2007-06-22, at 10:47 EDT, David Temkin wrote:

Got it. That makes sense.

But it also brings up another issue re: Flash 9 and presumably  
Tamarin-based Firefox. How do sealed classes interoperate with  
LZX concepts like <state>? To put it another way, what extent are  
LZX semantics affected by the Javafication of Javascript?

Does a sealed class allow any changes at runtime -- properties  
being added/removed, for example?



No.  Sealed (really not dynamic -- sealed is the default unless  
you use the `dynamic` adjective when declaring your class) means  
you cannot add or remove properties at run time.  This is required  
for the optimization.  The slots of a sealed class are assigned a  
fixed offset, so there is no need for a run-time hash lookup.   
Even more importantly, if types can be inferred, there is no need  
for method dispatch -- you can directly call the method.

There are two ways to 'loosen' that constraint.  Declaring the  
class dynamic, presumably reverts to using a hash for property  
lookup.  This has the disadvantage of making the whole class  
slower.  There is also a `prototype` declaration for individual  
slots on a class, which makes those slots have Javascript 1  
semantics (they can be redefined in an instance).  I don't know  
what the performance implications of that are -- presumably it is  
less costly than making the whole class dynamic, but I don't know  
by how much.  This is something we will have to think about:   
whether we can do enough analysis in our tag compiler to make the  
optimal choices when emitting the JS2 class declaration.

On Jun 21, 2007, at 7:30 PM, P T Withington wrote:

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 <[EMAIL PROTECTED]>
To: Bret Simister <[EMAIL PROTECTED]>,  
Chris  Pettitt
<[EMAIL PROTECTED]>, Dave Nault
<[EMAIL PROTECTED]>, Elliot Winard
<[EMAIL PROTECTED]>, Scott Evans
<[EMAIL PROTECTED]>, John Sundman
<[EMAIL PROTECTED]>, lchouanard
<[EMAIL PROTECTED]>, Mark Davis
<[EMAIL PROTECTED]>, Pablo Kang
<[EMAIL PROTECTED]>, qa <[EMAIL PROTECTED]>,  
Sarah
Allen  <[EMAIL PROTECTED]>, Yossie Silverman
<[EMAIL PROTECTED]>, David Temkin
<[EMAIL PROTECTED]>

Change 51366 by [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
https://hedwig.laszlosystems.com/mailman/listinfo/internal-dev

To search the dev list: http://lists.laszlosystems.com/ 
intranet/finddev.cgi