Hi John, On Fri, 24 Aug 2012, jwhitten wrote:
> Nobody said "unexpected"-- I said "unexpected" ... ;-) > those happen frequently enough on their own, we don't need to codify that! :-) What I am trying to say is that it can easily become unexpected when a getXXX() call changes XXX (or has other side-effects). While x = stack.pop() is self-documenting (at least of one knows what pop means) x = getStack() (when actually popping the top value) would be rather unexpected, don't you think? At least my simple mind could be easily confused, if getProperty() does funny things in addition to returning properties value. Not that I don't understand your arguments or use cases, I would probably still try to avoid such usage of properties. > As long as the behavior is properly documented there is nothing "bizarre" > about a read-only property, or a read-property which has side-effects. And I do prefer code that doesn't need "proper documentation" (not that I would always succeed in that ...). > A great example is the notion of a "serial" data type, such as in a > database. Nobody freaks out when you read it once and it's one number and > you read it again and it's a different number. The trains don't stop and > the stars don't fall from the sky. And in fact, in CONTEXT, it is the > EXPECTED and NORMAL behavior for the property. Hmm, in PostgreSQL you actually read a sequence (SERIAL) with either currentval() or nextval(), only the latter incrementing it (before returning its value, I believe). > It's all in your perception. I agree. Cheers, Fritz > > > Here is a page from Wikipedia [ > http://en.wikipedia.org/wiki/Property_(programming) > http://en.wikipedia.org/wiki/Property_(programming) ] on the subject: > > /"A property, in some object-oriented programming languages, is a special > sort of class member, intermediate between a field (or data member) and a > method. Properties are read and written like fields, but property reads and > writes are (usually) translated to get and set method calls. The field-like > syntax is said to be easier to read and write than lots of method calls, yet > the interposition of method calls allows for data validation, active > updating (as of GUI visuals),* or read-only 'fields'*. That is, properties > are intermediate between member code (methods) and member data (instance > variables) of the class, and properties provide a higher level of > encapsulation than public fields."/ > > > Another clip from the Wikipedia [ > http://en.wikipedia.org/wiki/Uniform_access_principle > http://en.wikipedia.org/wiki/Uniform_access_principle ]: > > "Meyer recognized the need for software developers to write code in such a > way as to minimize or eliminate cascading changes in code that result from > changes which convert an object attribute to a method call(or vice versa). > For this he developed the Uniform Access Principle. > Many programming languages do not strictly support the UAP but do support > forms of it. Properties, which are provided in a number of programming > languages, address the problem Meyer was addressing with the UAP in a > different way. Instead of providing a single uniform notation, properties > provide a way to invoke a method of an object while using the same notation > as is used for attribute access. The separate method invocation syntax is > still available. > > UAP Example > > If the language uses the method invocation syntax it may look something like > this. > > //Assume print displays the variable passed to it, with or without parens > //Set Foo's attribute 'bar' to value 5. > Foo.bar(5) > print Foo.bar() > > When executed, should display : > > 5 > > *Whether or not Foo.bar(5) invokes a function or simply sets an attribute is > hidden from the caller.* Likewise whether Foo.bar() simply retrieves the > value of the attribute, or invokes a function to compute the value returned, > is an implementation detail hidden from the caller. > > If the language uses the attribute syntax the syntax may look like this. > > Foo.bar = 5 > print Foo.bar > > *Again, whether or not a method is invoked, or the value is simply assigned > to an attribute is hidden from the calling method.*" > > > As I indicated previously, this is not a new concept, and in fact, is > implemented rather widely in other languages and environments. > > :-) > > John Whitten > > > > > > fritz wrote >> >> John, >> >> code with (unexpected) side-effects seems to be playing with fire ... >> >> Certainly something that should be documented in the code specifically >> (just >> think about somebody else having to maintain your code at some point in >> the >> future or yourself 6 months from now). >> >> And isn't a read-only property somewhat counter intuitive as well? >> >> Cheers, >> Fritz >> >> On Fri, 24 Aug 2012, jwhitten wrote: >> >>> Alexander, >>> >>> THANK YOU very much for your swift response. I will implement my own >>> scheme then. >>> >>> However, just for the sake of discussion-- read-only properties are quite >>> useful in a number of scenarios, as well as read properties which have >>> side-effects. And the concept is not a new one, read-only properties >>> (including properties with side-effects) are available in a number of >>> other languages. >>> >>> A property, generally, should be one of the "publicly-accessible" data >>> elements of an object. However, not all of these data elements should >>> necessarily be allowed to be changed-- at least not externally. On the >>> other hand, practically-speaking, handling that type of operation is easy >>> enough-- just simply create a "blank" (do-nothing) writer (setter) that >>> ignores the write. But it would be nice if it could just be a boolean >>> flag >>> that could be set in the property declaration. >>> >>> It's the other item that I'm actually more concerned about. I have a >>> number >>> of situations where I want to "present" information in the form of a >>> "read-only property", meaning that I would like to declare it as part of >>> the >>> "publicly-accessible data elements" but NOT have it act as a simple >>> getter. >>> Instead, the "get" handler could be specified, just as the write handler >>> can >>> be specified and in similar fashion, the action of the getter is >>> overriden. >>> >>> One possible use would be to create a "time" property. Which is a >>> volatile >>> data element, and every time it is read, it is (internally to the object) >>> mapped to a function which returns the current time. >>> >>> Or a serialized (serial) number, for instance. Or perhaps a one-time key >>> for cryptology through a read-only property which always returns a >>> randomly-generated key. >>> >>> In my present case, I'd simply like a "publicly-declared property" which >>> returns the current page index value. Or a flag indicating whether we're >>> at the beginning or the end. >>> >>> Of course, each of these items can certainly be handled by a >>> publicly-accessible method as well. But then again, so can any other >>> property you care to name. :-) >>> >>> >>> Thanks! >>> >>> John Whitten >>> >>> >>> Alexander Steitz wrote >>>> >>>> Hi John, >>>> >>>> incrementing a property with every READ operation is not possible for >>>> the >>>> qooxdoo property system. To be honest, this would be a strange behaviour >>>> from my point of view, since this wouldn't be a normal "get" anymore. It >>>> would an implicit "get" and "set" within one operation. >>>> >>>> My advice is to go for an own implementation for this use case. Also the >>>> READ-ONLY mode is not supported by the property system. You have to >>>> implement it on your own. >>>> >>>> Regards, >>>> Alex >>>> >>>> -----Original Message----- >>>> From: jwhitten [mailto:john_whitten@] >>>> Sent: Friday, August 24, 2012 4:05 PM >>>> To: [email protected] >>>> Subject: [qooxdoo-devel] READ aspect of Custom Properties - HELP Please >>>> >>>> >>>> Hello, >>>> >>>> I've been working on some custom classes (objects) and I've read through >>>> the Properties section of the manual several time, searched the list and >>>> Google-- and I'm not seeing anything about handling the READ aspect of a >>>> property. Both in the sense of creating a READ-ONLY property, and in the >>>> sense of creating a property that has a READ side-effect (ie., something >>>> that happens just because the property was read). >>>> >>>> Could one of you helpful and knowledgeable folks tell me about the READ >>>> aspects of properties? How can I create a property that, for instance, >>>> increments by one, every time it is read? >>>> >>>> Similarly, how can I create a property that can be read but not written? >>>> I >>>> know I could probably write a custom writer and block [ignore] the data, >>>> but part of the general concept and methodology of the property system >>>> is >>>> to have a lot of that happen "auto-magically" under-the-hood so that all >>>> I >>>> should have to do is declare the property "READ-ONLY" or some such and >>>> then it becomes protected, and perhaps only permits an internal writer >>>> (setter). >>>> >>>> Thanks for any assistance you can provide! >>>> >>>> Qooxdoo is a terrific platform and well worth investing time in!! Thank >>>> you VERY MUCH for all your hard work and efforts. I'm sure I'm not alone >>>> in appreciating it! >>>> >>>> John Whitten >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://qooxdoo.678.n2.nabble.com/READ-aspect-of-Custom-Properties-HELP-Please-tp7581097.html >>>> Sent from the qooxdoo mailing list archive at Nabble.com. >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and threat >>>> landscape has changed and how IT managers can respond. Discussions will >>>> include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> qooxdoo-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. >>>> Discussions >>>> will include endpoint security, mobile security and the latest in >>>> malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> qooxdoo-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://qooxdoo.678.n2.nabble.com/READ-aspect-of-Custom-Properties-HELP-Please-tp7581097p7581099.html >>> Sent from the qooxdoo mailing list archive at Nabble.com. >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> qooxdoo-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> >>> >> >> -- >> Oetiker+Partner AG tel: +41 62 775 9903 (direct) >> Fritz Zaucker +41 62 775 9900 (switch board) >> Aarweg 15 +41 79 675 0630 (mobile) >> CH-4600 Olten fax: +41 62 775 9905 >> Schweiz web: www.oetiker.ch >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > > > -- > View this message in context: > http://qooxdoo.678.n2.nabble.com/READ-aspect-of-Custom-Properties-HELP-Please-tp7581097p7581103.html > Sent from the qooxdoo mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- Oetiker+Partner AG tel: +41 62 775 9903 (direct) Fritz Zaucker +41 62 775 9900 (switch board) Aarweg 15 +41 79 675 0630 (mobile) CH-4600 Olten fax: +41 62 775 9905 Schweiz web: www.oetiker.ch ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
