PRO_LIB_CORE_TUTORIAL_R1

[Astea]

wiki page: PRO_LIB_CORE_TUTORIAL_R1 - effort: 3d

[boyan]

The analysis is really well written and provides sufficient and detailed information.

[boyan]

forgot to fill my name in the reviewers field

[meddle]

• Ummm "Let's say we've got lots of object which we're using in our application. These object depends on each other in a sense that: "... lots of object??
• In the implementation phase you can provide some revisions with your images containing the diagrams for the tutorial. We can merge them to the trunk and fix the links in the tutorial to point to the trunk images.
• The @Const AutoProperties rarely depend on anything, they are "bottom" properties that can canculate themselves by themselves only once. The greatest example for such an AutoProperty is:

  	@Const
  	public Prop<Link> link() {
  		class link extends AutoProperty<Link> {	
  
  			@Override
  			protected Link compute() {
  				assert getLastValue() == null;
  				return new FrameLink(getChangeManager());
  			}
  		}
  		return getBean().makeProp(link.class);
  	}
  

• May be you should mention that the calling order of the @Setup methods is not defined.
• But ProObjects that are in Properties annotated with @Own are not obligated to define a ParentProperty, you should mention that.
• "It should contain cycles, otherwise we can never initialize this graph.", may be shouldn't?
• You should describe in more details how the ProLib works... The Registry, the ProListeners and most importantly the AutoTracker. How the AutoProperties update is something that only 2-3 people know.
• Add a section how to use the eclipse templates for the ProLib.

3.5p (90m)

[gogov]

Nothing new, just moving to im_fi

[gogov]

ok, added some more comments

[pap]

• The tutorial provided is quite nice and understandable. It is much better than what was before. But there are things that I think should be corrected
• First a small note that I think the RwListProp should be green and not red
• I think that it will be nice to mention that ProLib is Sophie independant. So you can use it for any application you like.
• I find the explanation of the doSet() for AutoProperties wierd and hard to understand. I think this method can be used when for example the AutoProperty computes a complex object of several simpler ones but also can decompose one such object ot its parts. I.e. ImmRect <-> (ImmPoint, ImmSize).
• The next things is about Meddle and his holy Jesus-like nature. I understand that you like each other very much and don't really mind if you include things like
  • " I also add this one by His Holy Meddleness request"
  • "Gogov 1:0 Meddle" etc

in the ticket comments or even in a tasks wiki page but this tutorial is several bits more important. And eventually this will only confuse readers that know neither Gogov nor meddle.

• Next are several issues with const auto properties
  • Actually the thing with the AP returning a "new MyObject" is quite important as it is a common case and also people tend to use other pieces of code whre they should use that
  • The first example is also good but it is important to mention that the properties we depend on should also be const AP or final properties
  • It would be nice to mention somehow that the "assert getLastValue() == null;" is not just some convention. It is a must for const APs
  • It may be nice to mention again the difference between const APs and final properties. And it is that APs know how to compute themselves whereas final and value properties do not (they get their values from somewhere aout there).
• Probably somewhere around here you could mention the use of Resource/Auto properties for synchroniztion purposes. Or maybe in a later part as this is not the most common use of such.
• I think it is better if you first give examples for a certain property kind usage through the most common case. The reason is in the ValueListProperty example.
• The example you give about the TrackingProList.filter.transform has one quite bad thing
  • The try/catch(NullPointerException) is a generally bad code example and I beleive such code should not exist in any kind of tutorial about programming (except if it points this is bad).
• The issue with the @Own annotation on a ProObject without parent() property is something bad as it really was supposed to be as meddle have told you. Maybe you would like to fix it as a part of the task :) Or report it as a bug
• Also it may be nice to mention that the parent() property of an object may be null if it is not yet attached to a parent object.
• You haven't mentioned the default value ability of value properties and the fact it should be a constant.
• The "Bad Code Examples" part is really short but I think that is not such an issue.
• About the debugging it would be nice to mention log/print instead of just print. This way you will promote logging that eventually is better for these purposes than printing
• Isn't there any wiki page about the Inspector you can provide a link to ?
• Fill in custom fields. You are the implementation owner after all :)
• You have placed the diagrams in some very strange place in the branch. These are documents and not test resources.

[gogov]

Ok, I'll fix some stuff but, this was meant to be a 3eff task!! I'll fail my current tasks because I think quality is more important, but I want to mention it.

• First a small note that I think the RwListProp should be green and not red -- agreed
• I think that it will be nice to mention that ProLib is Sophie independant. So you can use it for any application you like. -- though this was obvious, ok I'll add it as comment.
• I find the explanation of the doSet() for AutoProperties wierd and hard to understand. I think this method can be used when for example the AutoProperty computes a complex object of several simpler ones but also can decompose one such object ot its parts. I.e. ImmRect <-> (ImmPoint, ImmSize) -- ok, that maybe is another use case, which doesn't cancel the ones I've provided. If you want, I can add it, though then you should elaborate in detail, because I'm not totally sure what do you mean.
• The next things is about Meddle and his holy Jesus-like nature. I understand that you like each other very much and don't really mind if you include things like

o " I also add this one by His Holy Meddleness request"
o "Gogov 1:0 Meddle" etc

in the ticket comments or even in a tasks wiki page but this tutorial is several bits more important. And eventually this will only confuse readers that know neither Gogov nor meddle. --you integrator people don't have any sense of humor.. Ok, I'll remove these wake-up jokes but there's a danger the reader will fall asleep (:

• Next are several issues with const auto properties

o Actually the thing with the AP returning a "new MyObject" is quite important as it is a common case and also people tend to use other pieces of code whre they should use that -- I'll emphasize this in the @Own & ParentProperty section because there is the right place.
o The first example is also good but it is important to mention that the properties we depend on should also be const AP or final properties -- ?, I don't agree with that. Please elaborate.
o It would be nice to mention somehow that the "assert getLastValue() == null;" is not just some convention. It is a must for const APs -- point taken, though I think this is too much going in details.
o It may be nice to mention again the difference between const APs and final properties. And it is that APs know how to compute themselves whereas final and value properties do not (they get their values from somewhere aout there). --ok.. will repeat..

• Probably somewhere around here you could mention the use of Resource/Auto properties for synchroniztion purposes. Or maybe in a later part as this is not the most common use of such. --I've intentionally not put it here because people might think it's so cool and start using it, though as you know, this causes some design problems and I'd like to avoid it as much as possible.
• I think it is better if you first give examples for a certain property kind usage through the most common case. The reason is in the ValueListProperty example. -- I think this is the most simple case and don't agree the most common should be used instead. I explain things from simple to not-so-simple. But if more people think as you do, I'll change it.
• The example you give about the TrackingProList.filter.transform has one quite bad thing

o The try/catch(NullPointerException) is a generally bad code example and I beleive such code should not exist in any kind of tutorial about programming (except if it points this is bad). -- point taken.

• The issue with the @Own annotation on a ProObject without parent() property is something bad as it really was supposed to be as meddle have told you. Maybe you would like to fix it as a part of the task :) Or report it as a bug -- yeah, sure, I'll fix it.
• Also it may be nice to mention that the parent() property of an object may be null if it is not yet attached to a parent object. -- point taken
• You haven't mentioned the default value ability of value properties and the fact it should be a constant. -- point taken.
• The "Bad Code Examples" part is really short but I think that is not such an issue. -- effort 3... give me effort 6 and I'll write 20 bad code practices.
• About the debugging it would be nice to mention log/print instead of just print. This way you will promote logging that eventually is better for these purposes than printing. --don't fully agree but I'll add a comment.
• Isn't there any wiki page about the Inspector you can provide a link to ? --sure.
• Fill in custom fields. You are the implementation owner after all :) -- ok, ok..
• You have placed the diagrams in some very strange place in the branch. These are documents and not test resources. -- the previous diagrams were there, so I put them there. I don't mind moving them though we should agree on a place.

[gogov]

I think this bureaucracy is killing our performance.. We shouldn't write so much bullcrap here but should just talk and fix directly.. For the time you wrote your comments and I wrote mine, we could've finished all of this and more.

[pap]

Replying to gogov:

I think this bureaucracy is killing our performance.. We shouldn't write so much bullcrap here but should just talk and fix directly.. For the time you wrote your comments and I wrote mine, we could've finished all of this and more.

So it may be, but actually I lost most of the time reading the tutorial and writing the bullcrap actually helped me concentrate my thoughts and write something sensible. If I told you that inplace it would be some kind of humming. Probably its my personal problem that I am not inteligent enough to get things right and well and respond in seconds. Also you are not oblidged to write your comments. Actually you could've talked with me on the points you say need elaboration. Also if I had nothing to say we wouldn't waste any time but probably that wouldn't help us improve ourselves or the product. And last but not least there should be reasons for failing a task - that's my job and I have to document somehow why I wasted so much time. Again I am slow and certainly not as good as meddle or you.

---

[gogov]

Ok, sorry about the "bullcrap" term used. Actually I meant mostly the stuff I wrote because it was replaying to your stuff which happened because you weren't in the office.. I wrote it to respond and keep track of what's done according to your detailed reply..
And as you see, I agree with most of the stuff you proposed..
So I guess I'm also good enough to finish this task and I'll hand it to Peko, who has to work on core with me this week, so I hope I won't cause more trouble with this task..
Again, sorry about using "bullcrap".. It's like Meddle's "shit".. It's just a way to say stuff..

I'll fail my im myself.

[peko]

I think that the tutorial is quite full, descriptive and doesn't lack anything. I do like the tone with which it is written although it does not seem so formal this way. In addition some of the things mentioned are not added. As I read the tutotial, I think what should be changed is:

• More bad examples should be added indeed. This is also stated in the todo section.
• Code templates for properties should also be added. They should be put in two separated files as proposed by pap - one for single values and one for lists.
• Phrases like "(:", "stuff", "junk" and "His Holy" will be removed not because they are inconsistent but for formality issues.

[peko]

• A uml diagram added, as requested...

[kyli]

Spending so much time in arguing is sick.

[deyan]

Batch update from file query-obsoleted.csv