[vwnc] RE Platform priorities - How to support change
Locked
[vwnc] RE Platform priorities - How to support change
 
|
Thomas wrote:
>>
What could be changed to helps us contribute solutions (and get them included) to move things along? What is Cincom willing to do to support that?
"How to eat an elephant incrementally" opens the door to some obvious questions. To continue the analogy, once the use
of the knife is valued; the use of a freezer is next. The pieces of the elephant are still too much to consume quickly so there needs to be a way to store and exchange pieces. This shows one way to address the most obvious need of all, the incremental release
patch or "the freezer".
Changes to "working" code need to be allowed, but they must also be phased in with opportunity for review and under conditions that can accommodate change.
Consider an optimization of #trimBlanks that only incurs the cost of a creating new string if blanks existed to be trimmed. One could simply add a new method called something like #trimBlanksIfNecessary.
Ultimately though, it is more generally beneficial if the existing #trimBlanks were changed to answer self when no blanks need to be trimmed. It is understood that there are scenarios where this kind of change can cause a problem (like subsequently altering self
instead of an anticipated copy). It is also understood that a coding style that includes changing the contents of a string is rare, and so too is knowingly relying on #trimBlanks to answer a new string. In any case, let's say Cincom acts in a way that is long-term
advantageous to customers and makes this optimization to #trimBlanks; what is a reasonable way to achieve this goal...
A pause for a value statement...
There are risks to any change in behavior. Life is about taking reasonable risks instead of staying sheltered in bed all day. Obviously, life from a bed is limited and parasitic; it will expire
slowly from entropy. Life exists within (and to the extent of) reasoned risks. Liberty is an environment where risks may be taken and accountability is implicit.
Cincom's customers will appreciate that VW is a living product instead of a static one. The risk of change is to existing customer code--that only the customer can know. The risk is mitigated
through a process of informed consent and a period of review.
Informed consent -
Here is a patch and this is what it does; apply it now if you want because this behavior will likely be in the next release.
Period of Review -
The next release is likely to be in a month; we'd appreciate knowing if this patch should not be included or could be improved.
Fundamentals
explained, now to what is special about the patch...
The patch can be in the form of a parcel and distributed with configurable levels of automation. The parcel for this simple example would declare three methods to update one.
1) obsolete77_trimBlanks
The method exists as an executable notation showing the previously released #trimBlanks method that Cincom is
replacing.
2) nextRelease_trimBlanks
The method defines the proposed #trimBlanks that will likely be found in the next release.
3) trimBlanks
A method that overrides the existing #trimBlanks to send "^self assertPatchFor77 nextRelease_trimBlanks" to validate and enable
the new functionality.
The next VW release would define #trimBlanks that was #nextRelease_trimBlanks from the patch.
But you ask, "why not just have the patch define one #trimBlanks method to override when loaded?". Quite simply, I know not to trust VW overrides especially when there can be more than one loaded.
This is a safer, documented, comparable, and selectively reversible way that augments the VW overrides within the limits they can be relied on. I like to be able to easily find, compare, and expire patch changes.
BTW, Object>>assertPatchFor77 would be defined by VW 7.7 as a way to identify, note, and expire patches in future releases. #assertPatchFor77 would first just answer self but could be changed
in VW 9.0 to note patch obsolescence.
Customers can share patches in this form. Cincom would control what gets distributed.
Paul Baumann
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |