i haven't added up the votes, but there seems to be no super clear winner here...
i'm still sort of +/-0. but i do have two fairly strong opinions if we decide to get rid of IXxx naming that are stopping me from being +1 right now:
1. i strongly oppose using a meaningless name like DefaultModel or ModelImpl for what is clearly not either an Impl (meaningless) or a Default (again, this is incorrect by definition). i need to hear a really good name for the class that is currently called Model from the "rename it now" crowd that we can all get behind. the best i've heard so far is SerializableModel, which is an accurate name at least since a SerializableModel would wrap a Serializable object and the name would indicate something about the function of the class as well (that it will get serialized, and probably to any sophisticated user that it will be replicated in a clustered environment). i could go with SerializableModel, but others didn't like it so much (anyone changing their mind about that?). anyway, if we can come up with something decent we all like, maybe that would help us come together on this decision. so what is Model in this new naming scheme? SimpleModel? ObjectModel? SerializableObjectModel? cause it could no longer be a Model and it definitely ain't a DefaultModel. one nice thing, btw, about a name like SerializableObjectModel (which i'm kindof liking right now...) over Model is that it would draw attention /away/ from the class as some kind of default (which is a horrible idea to suggest to users (because it's a very inefficient way to create models) and something i don't like about the current name). if you think about it, (SerializableObject)Model really does accurately describe this class. it's a model that wraps a serializable object. i think it's okay if the name is a little obscure. we want people thinking about CompoundPropertyModel in the end, anyway.
2. i don't have much bandwidth for wicket right now and i don't want to waste the time i do have working on something as non-mission-critical as this. so someone else has to do it all. and if we do do this, the work done by someone else should include changing all javadoc, xdoc, text files and the wiki. it's going to be a small project to do this right and not leave dangling references all over the project to classes that no longer exist.
jon
Martijn Dashorst wrote:
All,
I would like to stress that I just choose IModel/Model as an example. We don't need to decide the naming for IModel/Model here, but the point is: Should we continue to use, in a consistent manner(!), the IFoo naming pattern, or do we use the same naming conventions as the (as Jon put it recently) best framework probably created: the Java collections package.
Furthermore, we should be *really* sure we don't want to perform the renames at a later time. As the moment to do so is /NOW/, not later. This is one thing that can't be postponed till 1.1. We might consider it for 2.0 but until that time, we will have to live with the coiche we make 'today'.
As for the comment Eelco made about liking the IFoo notation so you can easily find interfaces in Eclipse, I hate it, as I will get tons and tons of names of all IAaaaa till IZzzzzzz, so instead of limiting the choices you first expand the list. I *really* enjoy the naming convention of the collections package where you have a List instead of an IList.
Martijn
------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
