PreviousNext…

Go-getters 13 Feb 2004

OK, time for a really anal Notes coding question: do you use Property Get and Property Set in your custom Lotusscript classes at all?

I find that I do, despite my OO heritage (what there is of it) actually being more along the lines of Java, with its getHim() ooh, getHer() methods. What I mean is, I only really got in to object oriented Lotusscript after I got into Java.

It’s a weird one: I’m not convinced that the use of Property actually does much, beyond keeping one’s code consistent with The Lotusscript Way. For example, Notes programmers are used to seeing things like NotesDocumentCollection.Count, not NotesDocumentCollection.getCount(). A small distinction I know, but I told you I was being anal.

So, any takers? Any more persuasive reasons for using Property beyond being nice to Domino people? Indeed, one could argue the reverse postion: maybe we should think about using more get / set methods as we move further down the Java line at the expense of Lotusscript?

Filed under, , , ,

Comments

  1. I'm not sure I have a more persuasive argument, except that it makes them more intuitively "properties" as opposed to "methods". Since this is what I need to do internally for LSX development (Get code and Set code), but not what I want users to see (just think of it as the section title, don't worry about how we got it or change it), I like the approach.Ben Langhinrichs#
  2. i do write lotuscript classes, but never use those getter setter things. i know this isn't very encapsulable of me, but i just make whatever "properties" i want to do that for Public. anything i want to hide, i make Private. which is almost everything, most of the time, as i've learned the finer points of all this stuff.

    so if i have a public variable, to refer to it, its just

    object.varname

    which is nice and simple. but maybe it gets a little weird with publicly declared functions. then you have the same syntax to refer to both functions (method calls) and variables (fields).

    or i might make all the variables private and create functions to return them. i've done a bit of both, and now probably lean toward the latter. but i haven't used that get set stuff at all. maybe i should, to be honest when i looked at it, something about it just seemed a little weird. i never could get it to work, so i gave up. jonvon#
  3. Thanks chaps.

    I know what you mean jonvon, there’s a leeeetle bit of tinkering required the first few times when it comes to properties; Designer help is fairly scant on the subject.

    I got some working for my extended document collection and array classes, but nothing fancy mind!Ben Poole#
  4. hey maybe you could publish a little tutorial on that or something.

    ;-)jonvon#
  5. btw how did you like my use of the "word" encapsulable?

    :-D jonvon#
  6. Well, it's a bit extensillatious for my taste, but it'll have to do.Stan Rogers#
  7. Yes, I noticed your use of the word. I thought you were being a tad epithetulous, but no matter.

    The meaning was clear, and I think it’s safe to say that we were all in a state of comprehensivity.

    :-D Ben Poole#
  8. LOLjonvon#
  9. I remember asking about gets and sets on Rocky's site a few months back and a couple of people gave interesting responses.

    Since then, myself and my colleague agreed that we'd standardise on using 'get' and 'set' methods, instead of property gets and sets. The main reason we did this is because at least Java has a fairly consistent standard and every reduction in variation across multiple languages helps :-)

    The only other learned-the-hard-way advice I can give, is that property gets and sets might lead a user to think that you can pass that 'property' by reference to other functions, and after much hair tearing and debugging, you will learn that you can't. If you pass a property (obtained through the Get) to a sub, then it is always passed by value, and the property will not be updated. (It would be nice if the call stack had the good sense to call the equivalent Property Set as it unwinds, but I can understand that the LS engineers probably weren't big on that idea).

    In other words, don't ever try

    Call Updatify( thingy.mabob )

    Because mabob won't get updated. People would argue that Updatify() should actually be a class method, but that's not always practical.

    Once bitten, twice shy. I don't like surprises in code and I like things to be explicitly one way or the other, so that ambiguity and the potential for bugs pushed me over the "avoid 'em" edge.

    (I couldn't post this last night and the thread has meandered since. So, uh, supercalafragalisticexpialidocious :-)Colin Pretorius#
  10. Oooh good post. I definitely agree re consistency: go one way or the other, depending on your team’s area of expertise / general language direction I’d say.

    As for retrieving and assigning by value in nested statements, that’s a very good spot and worth emphasising, for sure.Ben Poole#
  11. You would either have to code the Updatify as a class method as you say and if that really is not practicable (etc) you would have to do this:

    thingy.mabob = Updatify (thingy.mabob)

    otherwise Updatify sets the values by side-effect.

    And properties return values not pointers (references) so yes you cannot manipulate a proprty liek a public variable, but isnt this the way OO encapsulationis meant to work. The above notation exposes a lot about the object. All this should/could be hidden. And then you would have this:

    thingy.Updatify (mybob)Slawek#
  12. Martin Fowler discussed properties, specifically in C#, just the other day:

    http://martinfowler.com/bliki/PublicCsharpFields.htmlBen Poole#
  13. My general rule of thumb is if a class member needs to be checked, validated, or converted, or if changing the member should spawn some other process, use a Get/Set. Otherwise, I usually just make things public and be done with it.

    Mostly I just get sick of writing all the stupid Gets and Sets just to change a variable. Classes are hard enough to look at in Domino Designer as it is -- if you add a dozen or so Get/Set blocks, it gets even more annoying to dig through.

    Once you get down to it, it's often a religious debate over whether to use Get/Set or not. Mostly it doesn't matter (except for the issue that Colin was talking about).

    One thing to keep in mind, though, is that with the Web Service implementation in Domino 7, they'll be using classes with public members to handle complex data types in SOAP messages (in the LotusScript implementation, anyway). Not that you need to design around something that's so far in the future, but that's something to think about…

    - Julian
    Julian Robichaux#
  14. Agree. I think we are sayng keep it simple. Yes it is bothersome to write the get/set properties. If I think its importnt to hide the class vars and one of them is an array or a list a property is just the thing then. Syntactically it has that little extra to a sub/function. This is especially on the set side.

    Not sure I agree entirely with standardising across multiple languages for the obvious reason that if you take it to its conclusion you will end up with the lowest common denominator, which negates using the different languages in the first place.Slawek#
  15. I don't think I agree with standardisation across languages either. I mean look at the LS Notes classes and the Java Notes classes. They are both different and respect the style of the 2 different languages. If you're a LS developer and want to use someone elses OO LS API, then you'd want something familiar. If you're a Java dude, then you want an API that is Java'ish.

    Thus:
    LS: NotesDocument.UniversalID
    Java: Document.getUniversalID()

    I love Java, but I'm not at all comfortable with making LS look like it.Andrew Tetlaw#
  16. I should clarify: I'm not in favour of contriving to remove differences: just that if there's no overwhelming reason to *be* different, then don't be different. I'd also challenge that the get-free LS Way is that 'pure'. Sure, we have doc.UniversalID(), but I just as often have to type getView(), or getNextDocument(), and so on. Yes, these imply activities and less along the line of property retrievals, but my point is that LS code sees its fair share of 'getting' as well.

    If I spend half a day trying to remember the C++ API versions, then switch to a java agent, then have to work on some LS code, I'm frazzled by the end. A little bit of consistency with no extraneous cost isn't a bad thing.Colin Pretorius#
  17. "my point is that LS code sees its fair share of 'getting' as well." But, as you point out with "Yes, these imply activities and less along the line of property retrievals" the 'getting' is only in name only, i.e. some class functions start with the word 'get'. That's only because 'get' describes the action.

    I take your point but have trouble imagining anyone creating an API in java that is more like LS because they want to add some consistancy.

    I think what's happening is that Java seems more like a 'grown-up' programming language and LS programmers want to be more 'grown-up'

    I think your bias against property get/set stems from your exposure to other languages. Your point about them being dangerous is interesting. Honestly I think only a C programmer would expect to pass a property into a sub and expect it to be changed, because you are used to being able to pass pointers around and have them changed. I don't think an LS programmer would ever expect that to happen.

    To a LS programmer there is a clear distinction between properties/functions/subs and so on that is reflected in the Notes LS class API:

    NotesDatabase.Title is a property that returns a string or sets a string
    NotesDatabase.GetView("xxx") is a function that performs an action and returns a NotesView
    NotesDatabase.Compact is a sub that performs an action only

    My contention is if you change the look and feel of the product, you may make it more difficult for the next pure LS programmer to come along. Which equals a dev/maintenance cost.

    We could argue this all day long probably, and we are all guilty of making public APIs to suit our own thinking, and it's always the case a new developer has to examine our APIs and try to understand our thinking. BUT, if you create an environment where things look and feel like other environments, then your poor old LS programmer can't really trust anything will work how s/he thinks it will in a purely LS world, adding to the burden of development.Andrew Tetlaw#

Comments on this post are now closed.

About

I’m a developer / general IT wrangler, specialising in web apps, the mobile web, enterprise Java and the odd Domino system.

Best described as a simpleton, but kindly. Read more…