1 - Hi,

How about the difference in speed between certain R5 vs. R6 @commands or @formulas ?

I heard from a few people, that certain expressions are very fast on R5, but very slow R6 (I assume this has something to do with rewrite of the @formula-engine in R6).


Jeroen

2 - Rock,

I think you should include "@SetViewInfo: the Agony and the Ecstacy", especially when used with Framesets!

3 - Wow, these are GREAT suggestions - keep them coming! I'll post some ideas as a followup later!

Rock

4 - Oh, @SetViewInfo and @GetViewInfo will definitely be a couple of the "acts" under the big top!

Rock

5 - Just as an aside...
Damien, I think that the reason for the underuse of @Transform is the documentation in Designer Help -- it is not at all clear that the transformed array is the result of the formula. The Help doc almost implies that the original array will be transformed in situ, since the only example in which the value is assigned has the value assigned to a field using FIELD -- it's never assigned to a variable. Of course, if you use the original array after running @Transform, it will be the same as it was before, therefore @Transform "doesn't work", and we'll move on to @For.

6 - Loops and the other new stuff in R6 would be one reason I'd go to that session.

Maybe another good section would be on comparing formula to script, speed comparisons etc.

7 - @Transform

Its wicked efficient, way better for looping over all elements than @For. People might actually use it if I had called it @ForAll or something like that.

8 - I would say also try to concentrate on the Formulas that were new in R6. I think many people may overlook them because they don't know they exist. Maybe hit on loops and such as well.

-Grey

9 - Damien is EXACTLY right - it is like @Replace, in that most people knew it existed but didn't realize all the crap that you can do with @Trim(@Replace). @Transform is POWERFUL. @Sort is too, especially with the ability to define your own sort patterns (how about length of string, shortest to longest, hmm? ).

More and more I think an "Formula Big Top" session would be fun - can you see the abstract I'm going to write?

"COME SEE amazing @function feats! WATCH lists transform before your very eyes! COMMAND single lines of code to do the work of TEN JAVASCRIPT LINES! GAZE at the beatiful @Sort as she "massages" your messy list into order!"

OK, I think we have a WINNA here!

Thoughts? BTW, I would love to have your "acts" for the Formula Big Top. If I use a trick of yours, you get full credit in the demo code and on the slides.

Rock

10 - On the contrary, Damien, I've yet to come across anything that wasn't measurably FASTER in the ND6 version. I'm sure that there are a few things that couldn't be optimized too much further, but in combination with other functions (how many formulas are single statements?), the overall effect is quite an improvement. I've recently ported a couple of tools back to R5 (in particular, dual-list and list-ordering dialogs), and the UI drag is quite noticible. One needs to pause ever so slightly between button clicks in R5, in ND6 they can keep up with the arcade kids.

11 - Extensive discussions on lookup caching would be useful. Most developers just throw "NoCache" around like there's no cost to it.

Also, some stuff on decent error handling techniques.

12 - A few thoughts:

Everything You Ever Wanted To Know About Lists* But Were Afraid To Ask

NULL Is A Keyword, And Other Formula Myths

Refactoring Old Notes Code With New Formula Language Features

-rich

13 - Does anyone have any specifics about Jeroen comments on performance? Not that I can do anything about it, but I've never heard that anything is measurably slower in R6 and I'm curious.

14 - Rocky,

I'd love to see an advanced formula session. I tend to go to Lotusscript for anything complex, so I sometimes miss out on just how far along the formula language has come.

r.