[dia] More readable comments
- From: Hans Breuer <hans src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [dia] More readable comments
- Date: Wed, 6 Oct 2010 21:59:39 +0000 (UTC)
commit d8d735fad74a71cd2e2f343fd355b5257683810d
Author: Hans Breuer <hans breuer org>
Date: Fri Sep 24 19:18:22 2010 +0200
More readable comments
objects/UML/umlattribute.c | 22 +++++++++++++---------
objects/UML/umloperation.c | 22 +++++++++++++---------
2 files changed, 26 insertions(+), 18 deletions(-)
---
diff --git a/objects/UML/umlattribute.c b/objects/UML/umlattribute.c
index 235a512..92ddb2a 100644
--- a/objects/UML/umlattribute.c
+++ b/objects/UML/umlattribute.c
@@ -223,15 +223,19 @@ uml_get_attribute_string (UMLAttribute *attribute)
}
/*!
- * The ownership of these connection points is quite complicated. Instead of being part of the UMLAttribute as one may expect
- * at first, they are somewhat in between the DiaObject (see: DiaObject::connections and the concrete user, here UMLClass)
- * and the UMLAttribute.
- * But with taking undo state mangement into account it gets even worse. Deleted (to be restored connection points) live inside
- * the UMLClassChange until they get reverted back to the object *or* get free'd by umlclass_change_free()
- * Since the implementation of attributes/operations being settable via StdProps there are more places to keep this stuff
- * consitent. So here comes a tolerant helper.
- *
- * NOTE: Same function as uml_operation_ensure_connection_points(), with C++ it would be a template function ;)
+ * The ownership of these connection points is quite complicated. Instead of being part of
+ * the UMLAttribute as one may expect at first, they are somewhat in between the DiaObject
+ * (see: DiaObject::connections and the concrete user, here UMLClass) and the UMLAttribute.
+ *
+ * But with taking undo state mangement into account it gets even worse. Deleted (to be
+ * restored connection points) live inside the UMLClassChange until they get reverted back
+ * to the object *or* get free'd by umlclass_change_free()
+ *
+ * Since the implementation of attributes/operations being settable via StdProps there are
+ * more places to keep this stuff consitent. So here comes a tolerant helper.
+ *
+ * NOTE: Same function as uml_operation_ensure_connection_points(),
+ * with C++ it would be a template function ;)
*/
void
uml_attribute_ensure_connection_points (UMLAttribute* attr, DiaObject* obj)
diff --git a/objects/UML/umloperation.c b/objects/UML/umloperation.c
index c5844cd..4fe9e7b 100644
--- a/objects/UML/umloperation.c
+++ b/objects/UML/umloperation.c
@@ -429,15 +429,19 @@ uml_get_operation_string (UMLOperation *operation)
}
/*!
- * The ownership of these connection points is quite complicated. Instead of being part of the UMLOperation as one may expect
- * at first, they are somewhat in between the DiaObject (see: DiaObject::connections and the concrete user, here UMLClass)
- * and the UMLOperation.
- * But with taking undo state mangement into account it gets even worse. Deleted (to be restored connection points) live inside
- * the UMLClassChange until they get reverted back to the object *or* get free'd by umlclass_change_free()
- * Since the implementation of attributes/operations being settable via StdProps there are more places to keep this stuff
- * consitent. So here comes a tolerant helper.
- *
- * NOTE: Same function as uml_attribute_ensure_connection_points(), with C++ it would be a template function ;)
+ * The ownership of these connection points is quite complicated. Instead of being part of
+ * the UMLOperation as one may expect at first, they are somewhat in between the DiaObject
+ * (see: DiaObject::connections and the concrete user, here UMLClass) and the UMLOperation.
+ *
+ * But with taking undo state mangement into account it gets even worse. Deleted (to be
+ * restored connection points) live inside the UMLClassChange until they get reverted back
+ * to the object *or* get free'd by umlclass_change_free()
+ *
+ * Since the implementation of attributes/operations being settable via StdProps there are
+ * more places to keep this stuff consitent. So here comes a tolerant helper.
+ *
+ * NOTE: Same function as uml_attribute_ensure_connection_points(),
+ * with C++ it would be a template function ;)
*/
void
uml_operation_ensure_connection_points (UMLOperation* op, DiaObject* obj)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]