Now, that's exiting: Until now, each of your ideas easily rocketed away in promotes. Can't wait to see, how this one develops ...

... and good Lord, what kind of massacre is gonna take playe, if Willy Lorenzo himself gets the news?

I don't understand why there are demotes to this idea. The extended syntax does not allow the compiler to "check" the method- and property-names of the class NotesDocument.
So there is no warning for errors like doc.GetItemValues("Subject") instead of doc.GetItemValue("Subject").
For all other objects this would raise an error "not a member: GetItemValues".

I am failing to see the big benefit of this. It would break (most?) existing applications if turned on. I understand that improvements to the language would be possible. All the current applications would break anyway, if a new property happened to match a field name. And with many Notes applications in production for 10 years or more, it would probably take at least 5 more versions of Notes until IBM could add new extensions to the language anyway.

BEN AND ROB DEMOTED IT!?!??! WTH!?!?!

@3 - Karl, Option Declare breaks a lot of code if you turn it on, too. And yet it's best practice for just about every Lotuscript engineer I know.

You wouldn't turn it on unless you were going to modify the code it affected anyway. It's JUST LIKE Option Declare.

Does anyone think that Option Declare is a bad idea?

I'll reserve my vote until I get clarification on why Ben et al demoted, but it certainly seems like a good idea. To be clear, this would NOT break existing code. As Nathan points out Option Declare is just that - optional. Leave existing code alone and it just keeps working as it does.

I can certainly see where some fans of the technique might not like to inherit code with this turned on, but it wasn't THAT hard to get over having to declare all my variables.

It's a great idea, at least for someone like myself who never uses extended syntax and ends up confused when I run across it. However I only promoted this on the assumption that autocomplete in Designer 8.5 is going to be *flawless*. Today autocomplete works often enough to be frustrating when it doesn't, and Ctrl+Space works so infrequently I gave up trying to use it. If autocomplete isn't going to be perfect I can't support taking away the shortcuts that make development easier.

I'll post a revised version of the comment I made to Nathan...

Religious wars on style don't need to be fought in public. There is nothing inherently bad about extended notation. If you don't want to use it, don't. If you feel it is important that developers working for you shouldn't use it, tell them so. Don't make a simple language harder because you wish you were working in a more advanced language. LotusScript is what it is, and part of the power is the simplicity. Adding a setting that would make perfectly reasonable code, including much of the sample code found in forums and elsewhere, not syntactically correct because of a pseudo-religious opposition seems hardly fitting, and certainly makes life harder for junior developers who wouldn't understand why perfectly reasonable sample code doesn't work.

For what it is worth, I use extended notation frequently. I put it in samples I give people. I would be upset if they started writing back and saying "That code you posted doesn't work" and I were to find out that the reason was that somebody chose to impose their stylistic views by force. There are times I choose not to use extended notation, but I think this bit of objecting to its use is ridiculous and makes a lot of code harder to read and harder to use for beginners, which is part of why I think more advanced users do it - to show their superiority. Just my opinion, of course.

And for what it is worth, I find being asked to justify this somewhat objectionable. People have a right to think ideas are good or bad without being called out to justify those positions. This is a bad idea, so I demoted it. Enough said.

@7 - Sorry, Ben. I'll never ask again.

LMAO at your use of "impose their stylistic views by force."

*sigh* I didn't want to debate this. I still don't. I even withdrew my "no" vote for a while. And for what it's worth, this very discussion is the reason I opposed publicizing the names behind the votes on IdeaJam to begin with (look at really old IdeaJam suggestions if you think I'm kidding). To his credit, Nathan is simply genuinely surprised that people disagree, and really wants to know why. Ultimately, though, since I've been called out by name in public, I guess I have to say something in public. Short version: I agree with everything Ben said. My original (emailed) response to Nathan is below.

I don't know Ben's reasons, but I'm sure they're better than mine. My reasons are relatively simple:

* I don't agree with the fundamental premise, that the extended notation is inherently evil (your "many people" citation is accurate, and you correctly didn't say "everyone"). That is the difference between this and "option declare" to me - there was never a question that neglecting to declare a variable was a Really Bad Idea (TM).

* I also don't agree with the corollary that the existence of the extended notation makes it impossible for the compiler to do a better job of error detection (the properties and methods are known, anything else must be a field name; this does not appear to be rocket science).

* More to the point, I don't think the idea is necessarily *bad* but I also don't consider it an unalloyed good thing. The reason I voted "no" instead of simply abstaining was to raise the caution flag and make people think. Many people blindly follow the lead of people they consider "alpha" geeks in our community, and you are certainly one of those who can lead others in his trail (not a bad thing, and also not your fault, just reality). If your idea stands without any opposition, you will have 100 votes from people who didn't even think about it. If a few people oppose your idea, at least those 100 people MIGHT have paused for a second before voting.

I suppose I should provide a little more background on what I thought was a no-brainer idea...

I'm generally pretty good at avoiding extended syntax. I do that for two reasons: 1) performance (IBM says there's a hit, if a small one); 2) forward compatibility (how many people had apps break in 6 because they had a field called "Lock"?)

If that's not important to you, no problem -- just don't turn on that switch. Or turn it off when your compiler barfs.

But I wished for it today when I was debugging something that kept erroring on...

If document.IsRepsonse Then...

How nice would it be to catch that at compile time and never have had to deal with unit failures on it?

Thanks Ben, but please understand that knowing the *why* behind your vote matters more because of who you are. Your comment will help crystalize the issue for many people, myself included, and allow them to make a more informed decision. Otherwise many people might just go "sounds reasonable" and promote it just because its Nathan's idea.

That said, I still think the upside of having the option is high enough to justify a promote, since again, it is optional. As long as the compile error this generates is meaningful (i.e. "Not a recognized method or property of NotesDocument - Option NoExtendedClass enabled"), I'd be fine with it.

My first reaction was - what's wrong with the extended notation?

I don't think anything is wrong.

That said, I don't see any problem with providing this as an option (off by default) for those that want a more rigid syntax check. While not using Option declare is as Rob said a Very Bad Idea, this would be more of a preference and skill level thing - like using procedural vs OO coding.

I have mixed feelings about this one.
The performance effect of extended notation is pretty minor.
The possibility of code being affected by a new property or method matching one of the field names is more important, but it still only affects code that's edited -- existing apps don't break (unless they've got something weird going on that causes a recompile every time a design element is used -- and that CAN happen, but is unusual).
Since it's not a drop-dead obvious benefit, I think the development team's time would be better spent on other things which are DDO. Especially since this is one of a large number of code quality issues (like unused variables, missing Byvals, missing Option Declare statement) that could be addressed by outside tools that, I hope, partners will write once they can get their hooks into the editing environment via Eclipse.

LOL.... well, I guess this is a more polarizing issue than I would have guessed!

I suppose that's what IdeaJam is for, after all. Okay :)

Of course extended notation is evil. It injures maintainability by promoting unnecessary hard coding of item names. Use of string constants is the correct approach.

Okay, for example snippets, it improves readability, and so clarity of the message, so in that way it is useful. Thus it would (ought to) be another among a number of such shortcuts used with snippets. No problem there.

Adding the OPTION Nathan advocates is a measured way to promote better practice while maintaining backward compatibility whenever or wherever needed.

All IMO, naturally.

The trend in scripting languages is toward optional type declaration (Ecmascript 4 and the javascript engine in XPages). Option ExtendedSyntax would be consistent with that direction. While there could be some pain as is Ben's scenario, it nets out as a plus for me.

{ Link }

@15 Then you'd be in favor of a linked idea for a compiler switch banning the passing of any string literals as parameters to any methods (getItemValue, getView, etc)? Just curious...

Dan - As far as I can tell, extended notation has nothing whatsoever to do with optional type declaration. That is far more related to Option Declare than to this idea.

Paul - Please tell me how

doc.Title = "This is the title"

is vastly less maintainable than

Call doc.ReplaceItemValue("Title", "This is the title")

It might possibly be more maintainable with

Call doc.ReplaceItemValue(fieldname, "This is the title")

but this option would not either assist or prevent that. There is nothing more "hard-coded" about the first than the second statement.

I went ahead and promoted this, simply because I like the idea of being able to finely control (tune?) one's development environment.

HOWEVER I do not think that extended syntax is, in and of itself, a bad thing. I do not normally use "dot notation" simply because the resulting code fails my IOCDCC* -I think extended syntax looks ugly. I understand that other developers may have different tastes than I regarding dot notation; I'm even willing to concede that in some cases they may be right in doing so. Which, if you think about it, is a good reason for promoting this idea. It would be a compiler OPTION - not a requirement.


*IOCDC = Internal Obsessive Compulsive Disorder Control Check

Nathan and I don't agree on everything, but extended syntax is definitely one of my pet peeves.

- Option Declare lets you catch more bugs at compile time instead of run time, but, as Nathan pointed out, extended syntax reduces that ability.
- The reason I like having Option Declare automatically included is that it enforces variable declaration from the outset, so that whoever inherits my code doesn't have to clean it up later (well, okay, not as much). While the compatibility issue may not impact design elements until the next modification, it can be a huge productivity drain if, following an upgrade, numerous design elements can no longer be modified without first fixing what wouldn't be broken if extended syntax hadn't been used. Given a choice between something that might break (though, admittedly, the *vast* majority of item names we reference will never become a class member) and something that is pretty much guaranteed not to break, why would I possibly choose the former?

The *only* advantage I can see to extended syntax is that it saves a half second per item while coding. I do agree that this is mostly a matter of personal preference, and should probably be a lower priority than some of the other items we're waiting on, but we get new INI variables all the time for fringe use cases, so perhaps an INI setting that any given developer could enable that doesn't store the setting within design elements, but flags at compile time any use of extended syntax.......

Ummm. Nathan - best to find out *why* people dislike the idea before getting excited.

I can see both ends of the argument... And I voted for you because in the apps I see, this would be very very useful. This doesnt mean Ben's wrong.. ;-)

---* Bill

@21 - Agreed, and that's why I went and asked those individuals for explanations -- so we could have a discourse about it, instead of blindly picking parties in the voting booth.

And truthfully, I'm not in disagreement with what Rob and Ben and others have pointed out as the advantages of extended syntax. Which is why I didn't suggest it be deleted from the source code. I would just like to be able to control the default behavior of the compiler, much as I can set a myriad of other options today.

I mean, it's not like the code to check the validity of members on a product class isn't there. It runs for EVERY OTHER CLASS except NotesDocument. So it seems quite likely that there's some special case that says "if it's a NotesDocument, then SKIP all this" in the compiler. And I'd like to be able to say "no, no... even if it's a NotesDocument, go check just like if it was a NotesView or NotesSession or NotesEmbeddedObject."

But I don't want to require that you check. Or that Rob checks. Or that Ben checks.

Nice, pretty much the discussion that I had expected.

I'd like to throw in one point, that I hardly see mentioned anywhere: Up to R5, ReplaceItemValue had a nasty side effect, when the item wasn't in the doc, yet. The IsSummary property of the new item would default to False. Since Notes 6, this is no longer the case, but judging from my experience, how long it takes people to adopt stuff, maybe some are still not aware of that change.

And no, this is NOT aimed at the well respected community members, who chose to demote this idea. It's just a general reminder and an explanation, why I personally do use the full syntax much more light-heartedly, than I did back then.

Extended notation is built in to the LSX Toolkit, which means a couple of things. First, the basic functionality is part of the LotusScript class logic, not a special feature of NotesDocument (even if that is the only base class that uses it). Second, other people, including me, have built it into other classes, so NotesDocument is not the only class. It is simply the place where in made the most sense in the base Notes classes. I think, although I am not sure, that is was also used in some SmartSuite classes.

So, while it might be easy to check for NotesDocument, it might be quite hard to check for an LSX class that uses. It is possible you could intercept the call at a lower level, but it might be quite involved.

I'm giving this a "Promote" because I believe the extended object syntax actually makes LS HARDER for beginners to learn. I've seen too many examples in the LDD forums where newbies have mistaken the fieldnames used in extended syntax for intrinsic properties of the NotesDocument object -- they see code used in one database (where changing a field value has the side effect of moving a document between views, making it accessible to a scheduled agent, or whatnot) and fail to understand why "setting the same property" doesn't have the same effect in another application. Frankly, I'd think the 1337 attitude is "I know fields from properties -- I don't need any explicit method training wheels to remind me what's what."

I like the idea, and I think it ought to be something an organisation should be able to impose on its developers and contractors.

This is why I just demoted it rather than commenting at first. I appreciate the people who wanted to know my reasoning, but I don't see it shifting views much, as the inevitable battle is over whether extended notation is "good" or "bad", not over the choice to have a syntactic check or not. Stan cuts right to the chase - this is a step in the direction of organizations "imposing" this restriction, not a harmless choice as Nathan wants to portray it. If that is what people want, so be it.

As an aside, search the Gold forum and see how many code samples use extended notation. Those samples will all fail if this control is imposed. Think about it.

AH HA!!!

"other people, including me, have built it into other classes"

This explains so much!

And yeah, I actually wouldn't want to break your LSX.

Option NotesDocumentExtended False perhaps?

@18 - the trend is not specific to the type system...more compile-time options are being added. This was a close one for me. Most of the Notes DB Admin stuff I do is in python with extended syntax, operator overloading and string literals:

doc.someitem + = ['three','more','values']

Maybe the extended syntax check could be an tool option. Check it before the compiler (along with other code checks - see Buchan's recent post on tools). That way the Option wouldn't move around with the code.

Nathan - I don't use it currently for either Midas or OpenSesame, so it wouldn't cause me any great immediate pain. I have only used it for smaller LSX projects, although I have been tempted to allow Midas to use syntax such as rtitem.Table.Font = "Arial" which would be possible with extended notation. (Table would be a chunk defined as "Table 1") , which would allow you to set the font to Arial in a very quick shorthand.

@29 -- In that case, though, Ben, you are setting a property of an object, even if it is eventually stored as a value in a record in an item. The dot-chain syntax makes perfect sense in that case (although one could argue that something like rtItem.Table.SetFont("Arial") is equally valid). There's no confusion about the aim of the code.

And I've got to say that imposition of style is something an organisation should be able to do. Shops regularly check for things like the use of Option Declare and occurences of GetNthWhatever using QC tools like TeamStudio Analyzer before accepting code for production -- why should something like extended object syntax be treated any differently?

Take the doc.Lock example. Yes, it would work perfectly in R5, and would continue to work in Notes 6 and later -- until the moment that the code is edited. THAT's where ReplaceItemValue and GetItemValue have a maintainability edge. It's not about string literals, it's about making the code editable in the future without unintended consequences.

Nathan - No, you don't get it. There is no real property "Table", but there is a property "Font". The logic is that instead of saying

Set rtchunk = rtitem.DefineChunk("Table 1")
rtchunk.Font = "Arial"

or perhaps

rtitem.DefineChunk("Table 1").Font = "Arial"

you would say

rtitem.Table.Font = "Arial"

Thus, if you said

rtitem.Table18.Font = "Arial"

it would mean

Set rtchunk = rtitem.DefineChunk("Table 18")
rtchunk.Font = "Arial"

but only because the implied property "Table18" was interpreted at runtime. Does that make more sense? The place where this gets really interesting is when you say:

Call rtitem.Layer.AppendRTChunk(rtitem.Table2.Row3.Column1.Graphic)

which is somewhat clearer than either

Call rtitem.DefineChunk("Layer 1").AppendRTChunk(rtitem.DefineChunk("Table 2; Row 3; Column 1; Graphic 1")

or

Set rtLayer = rtitem.DefineChunk("Layer 1")
Set rtGraphic = rtitem.DefineChunk("Table 2; Row 3; Column 1; Graphic 1")
Call rtLayer.AppendRTChunk(rtGraphic)

Stan - No, you don't get it. There is no real property "Table", but there is a property "Font". The logic is that instead of saying

Set rtchunk = rtitem.DefineChunk("Table 1")
rtchunk.Font = "Arial"

you would say

rtitem.Table.Font = "Arial"

Thus, if you said

rtitem.Table18.Font = "Arial"

Set rtchunk = rtitem.DefineChunk("Table 18")
rtchunk.Font = "Arial"

but only because the implied property "Table18" was interpreted at runtime. Does that make more sense?

Balancing all the points made here, my own conclusion is that a compiler option is not the right way to go about doing this. In general, I think that an optional way to enforce non-use of extended syntax as a local coding standard is a reasonable thing, so while I don't share Ben's fundamental objection in that respect, I do think that he's got a good point about all that sample code out there that could not be imported into any application where the option is turned on. Andre mentioned eclipse, and that's where I think the solution lies. It should be an editor option, not a compiler option, and rather than just prohibiting extended syntax it should automatically convert extended syntax into the equivalent explicit method calls. That way, you can type it the way you're used to, or paste it in from any sample, and still have your local standards enforced.

Hey?! Where'd my comment go? Harrumph. Have to type it again :-(

So, balancing both sides of what's been said here, my conclusion is that a compiler option is the wrong way to go about doing this. In general, I think it's perfectly reasonable to want to enforce non-use of extended syntax notation as a local coding standard, so I'm not agreeing with Ben on that but I do agree with him that there's the practical matter of all that existing sample code to deal with. Andre got it right when he mentioned Eclipse, because this should be an editor option rather than a compiler option, and it shouldn't merely disallow extended syntax. It should automatically convert extended syntax to the appropriate explicit method calls. That way, you can type code the way you're used to, and you can paste it in from any source, and your local coding standard can still be enforced.

I'm now convinced that this is a tool and/or process issue. Changing my vote.

@Richard,

Your comment was there. Ben found a bug which we have fixed. Sorry about that. More cowbell please.

Actually, Ben, I DID get it -- and the syntax in your example is nearly consistent with dot-chain notation in just about every other language I use regularly. If you translate that syntax to a document and its items, though, it would run:

doc.FieldName.value = variable

where the item is an object grabbed through the document object and the value is the property you are setting. That's what you are doing by shortcutting the chunk definition in order to address a property of the chunk. It's no different, really, from grabbing a back-end document using:

Set doc = ws.CurrentDocument.Document

If Lotus had enabled an alternative syntax that made the Item's "objectness" clear instead of the misleading extended class syntax for the NotesDocument, there would be little problem (although I'd still be likely to use the more verbose version when type-ahead is available).

Okay, interesting debate.

I have to say, I come down on the side of giving the ability to turn this feature off. I, for one, don't like it, and never* use it. The problem for me stems back to the design decision in the very early days that MyDocument.MyItemName returns an array of item values, rather than a NotesItem object. It *should* have been, in my opinion, something like MyDocument.MyItemName.Values. In other words, the extended syntax would have been more 'acceptable' to those of Nathan and my thinking had it been a shorthand for GetItem rather than for GetItemValue.

The way it currently works introduces a major source of quite subtle (as per Nathan's doc.IsRepsonse) bugs, with no way of compile-time checking, and not even a sensible way of run-time checking. It's too late to fix that though. Which is why I'm voting FOR this suggestion.

@Richard, I see where you're going with your suggestion re making it a compiler option. The trouble with that is that code which compiled fine on one machine would not compile on a different machine, and while that's considered okay in the Java/Eclipse world, it's not behaviour that LotusScript developers would expect or easily accept. So on balance I think that the 'Option' option is the best solution to this.

Nobody is saying you HAVE to use this option. But I would choose to, and I would be grateful for the ability, when maintaining somebody else's code, to quickly turn this on and see all the extended syntax usage, even if I think turned it off again for a quiet life and to avoid RSI.

* Okay, "never" = "hardly ever"

In my previous response, for 'GetItem', of course read 'GetFirstItem'. Doh.
Can I make a suggestion for a 'preview' capability in the comments?? (Okay, I will do, separately!)

Stan (and Julian, sort of) - Interesting, I guess I hadn't thought of the distinction between extended notation as an object vs. extended notation returning the array as being part of the problem. So, in that light, JavaScript using the fieldname but returning an object is less objectionable, and less prone to error, than LotusScript's extended notation? I can see that would make a difference in syntax checking, which would address part of Nathan's concern, although obviously it is too late to change now. Still, it helps to see why people don't like what seems like a reasonable feature. It isn't solely because of the dynamic determination of the field but that it returns an array which can then be confused as a method. Thanks for elucidating that.

I think there are reasonable arguments for and against this idea and given that it would be optional, I don't see it as a significant problem. I demoted, however, because I don't think this is something that we should be encouraging the IBM Lotus developers to spend time implementing. Especially when the workaround is as simple as choosing for yourself not to use extended syntax or establishing coding standards in your own workplace.

As long as it's an option (extended on by default) I don't mind.
But personally I love extended notation, as it makes code much more readable, certainly within a with-end with construct.

I think this is a good idea from the point of view that extended syntax can be confusing - field names vs object properties. Other than that I don't think that extended syntax is a bad idea. It is not as powerful as using getItemvalue/replaceitemvalue calls as these can be parametrized for a far greater level of maintainability.

As an aside, if I come from a statically typed language background, both extended and standard notations let me access undeclared properties/fields. If I happen to mistype a field name I will not find out about it from the compiler, but not even at run-time. So I'd like an option I can turn on to check for the existence of a field at run-time with a catchable error being thrown when the field I am attempting to access does not exist in the underlying document. I just think that the current side-effect of returning an empty string when the field does not actually exist is misleading, to say the least.

How about Option EnforceFieldExists ?

Finally, if I was to improve on this idea of disabling ExtendedSyntax I would like there to be one global setting for such options that can be enforced on all the code in a database. Of course, individual pieces of code could still override those global options locally.

Interesting idea. I definitely agree with some of the points here:

- An Eclipse editor extension that automatically replaced extended notation as you were typing with .GetItemValue() or .ReplaceItemValue() would be pretty handy.

- @42 brings up a very good point. Code within a With/End construct is much easier to read with extended notation.

- This switch would be far more useful for GetItemValue cases than ReplaceItemValue cases.

I believe in the overall merit of the idea, however I don't believe it's something that LS dev should spend much time on at the moment, especially since this could be addressed somewhat elegantly with an Eclipse editor plugin. I'm not sure which way I'm voting yet.

Something that is important to this discussion is something I've suggested in various places: The capability to create classes that inheirit directly from the Notes core classes, e.g.:

Class MegaAwesomeDocumentClass as NotesDocument

If Lotus implements that capability then I believe that adds even more weight to Nathan's idea, which would definitely tip me in favor if a "Yes."

Slawek - Before you go adding a new idea for that, such enforcement would not be difficult, but it should not be at the Option level, but rather a property of the NotesDocument class, since it is not really a compile time property but rather a run time property, and one which LotusScript could not identify, but the class object could. Since LotusScript is an OO language, we should allow the object the right to complain about such things.

Ben - You're right. Sometimes it's too easy to just ask for more compiler options where I was talking about a run-time detectable exception.