Home » Language IDEs » Objectteams » Feedback on examples
| Feedback on examples [message #569137] |
Fri, 26 February 2010 11:04  |
 Aaron Digulla
Messages: 258
Registered: July 2009
Location: Switzerland |
Senior Member |
|
|
I've quickly browsed the examples. Here are my notes:
Stopwatch:
Why do I have to declare the imported methods abstract? Or rather: Why do I have to declare them twice? Why isn't it enough to simply say "start -> start;"?
If this is just an example and not really necessary, then please omit one of them, so we can see with how little code we can get away.
Observer:
"observers.removeAll(observers);" ... WTF? What's wrong with "observers.clear();"? I guess that this is because clear won't trigger the observers but from the code, this looks extremely inefficient.
In the code for "changeOpMany()", you call "deactivate()" but that method isn't defined anywhere.
Also, this code isn't exception safe: If an exception is thrown in "base.changeOpMany();", then the subject is dead. Therefore, a closure would be much better at this place.
Another optimization: in practice, changeOp should emit the old and the new value (and do nothing is they are equal or compareTo() returns 0). Can OT handle this? If so, by all means, show us. The current example is nice for a textbook but pretty useless in the real world.
Best regards,
|
|
|
| Re: Feedback on examples [message #569175 is a reply to message #569137] |
Fri, 26 February 2010 14:01  |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Hi Aaron,
Aaron Digulla wrote on Fri, 26 February 2010 06:04
> I've quickly browsed the examples. Here are my notes:
>
> Stopwatch:
>
> Why do I have to declare the imported methods abstract? Or rather: Why do I have to declare them twice? Why isn't it enough to simply say "start -> start;"?
>
> If this is just an example and not really necessary, then please omit one of them, so we can see with how little code we can get away.
I've added a paragraph titled "Alternatives". Please check whether it answers your question.
Aaron Digulla wrote on Fri, 26 February 2010 06:04
> Observer:
>
> "observers.removeAll(observers);" ... WTF? What's wrong with "observers.clear();"? I guess that this is because clear won't trigger the observers but from the code, this looks extremely inefficient.
>
> In the code for "changeOpMany()", you call "deactivate()" but that method isn't defined anywhere.
Fixed (With True Failthfullness).
Aaron Digulla wrote on Fri, 26 February 2010 06:04
> Also, this code isn't exception safe: If an exception is thrown in "base.changeOpMany();", then the subject is dead. Therefore, a closure would be much better at this place.
This is a good observation. OTOH, there's probably more to say about
exception safety than easily fits into this example. Yet I don't see how
a closure would change anything.
I could enclose the base call in try finally, but that would distract
from the core behaviour shown here. Interestingly, for the inverse,
i.e., temporarily activating a team, the within() { } block takes care of
exceptions, just as you request. Unfortunately, it cannot be used for
deactivation.
Aaron Digulla wrote on Fri, 26 February 2010 06:04
> Another optimization: in practice, changeOp should emit the old and the new value (and do nothing is they are equal or compareTo() returns 0). Can OT handle this? If so, by all means, show us.
That would require some knowledge about which data is being observed,
i.e., which field of the subject. Of course a callin method may do s.t. like
callin void changeOp() {
Object old = getObservedValue();
base.changeOp();
if (!old.equals(getObservedValue()))
for (Observer observer : observers)
observer.update(this);
}
This would make the pattern slightly less re-usable because now we need to
provide bindings for getObservedValue(), which may not always be feasible.
Also, using type Object for the value may not be optimal. What about primitive
data, e.g.? (not to mention the missing null checks in the above fragment).
Have you seen the specific solution in ObservingClose (the guard predicate)?
Aaron Digulla wrote on Fri, 26 February 2010 06:04
> The current example is nice for a textbook but pretty useless in the real world.
>
> Best regards,
So, please consider it as a textbook example :)
Those are the best for presenting the distilled concepts.
The ObserverPattern explicitly states: "Note, that a well designed program in
Object Teams will usually not require an explicit Observer infrastructure."
So all this is for illustration only.
The real production code you may browse in our SVN, but that's nothing to
be shown in a Wiki for first contact with the language.
Also the other examples (FlightBonus and OrderSystem) are a bit more
complete applications. (While they're not yet documented in the wiki, they're
easily accessible within the tool: New > Example > Object Teams > ...).
Thanks for your feedback,
Stephan
|
|
|
Goto Forum:
Current Time: Thu Apr 25 14:17:41 GMT 2024
Powered by FUDForum. Page generated in 0.03492 seconds |
] 
Search
Help
Register
Login
Home
