Kambiz wrote:Whenever it was saved to place a field in protected or public section, they are there. And, whenever it was possible I've provided a protected method for accessing to the private field. The remained private fields are really private variables an because of that without F prefix.
Naturally, one can choose to name anything <b><i>anything</b></i> other than reseved keywords, but my point in suggesting prefixing <b><i>all</b></i> private variables with an 'F' is merely to do with conssitency. It helps a lot when you're reading someone else's code. In the case of TS, renaming them doesn't affect any functionality, but improves readability. Then again, it is your code.
Kambiz wrote:Adem wrote:When there are a large number of nodes, it is very time consuming to iterate TSimpleGraph.Objects in order to find which node a particular node (TGraphNode) is linked to (and by what TGraphLink object).
Consider that since this release:
- Links as well as nodes can be hooked to a link. So, if we define a list of hooked objects, it should be contain of all graph object types.
- Two objects can connect together more than once. Because of that, you have to look again in all the objects to find all connections.
Maybe for some specific implementations we can use a list to speed up things, but in general it doesn't help so much.
There are three OnObjectHook, OnObjectUnhook, and OnLinkObjects events, and TGraphObjectList type that a host application can use it to build up a custom list of connected objects if needed.
Kambiz, you're defending a wrong design principle, <i>IMHO</i> and <i>with respect</i>.
An item (either a link or a node) should have all the information pertinent to itself in itself.
There is no significant difficulty in re-arranging the code to be that way; and, unless, by TSimpleGraph, what you really mean and emphasize is the <b><i>simple</b></i> part of it, the performance hit is <b>significant</b>.
One could use TSimpleGraph to depict a network (either a physical network, or a social network), or sitemap, or something similar and can easily come up with (hundreds of) thousands nodes.
There are very few things in TS that make it infeasible to use in such an application, the most important of which is <b>this</b>: You have to iterate all those objects to determine what uses what.
This information belongs with the item object; is static; does not change momentarily.. so, what rational is there to force the application to waste CPU power to retrieve it --Other than it is good enough for simple things.. and, that <b>it is <i>your</i> code</b>
