TOPIC: Question: naming of control classes

Hello All,

when naming subclasses of controls and windows, I would like to use the standard control class name and a prefix or suffix.

Example: the tools version of the TextBox class could be named TextBoxXST, or XstTextBox.

What do you would prefer: prefix or suffix? My personal preference is to use a prefix.
And what should the prefix/postfix be? Here my personal preference would be Xst for XSharp Tools.

Thank you very much for suggestions/wishes!

Wolfgang

I think, i prever prefix, as this sorts naturally. And "X" would imho suffice

Hi Karl,

thanks! You are right, an 'x' alone should be enough.

Wolfgang

Hi All

I suggest a prefix - x alone is too limiting - Xst would give more scope for searches later.

Reason: You may want to find all Xst Controls whatever they may be: Just search for Xst.
OK so you could do that with x alone.

But suppose you want to group something else in your searches - x has gone as an option.

Xst or Xctl is easier to read and interpret.

Just a thought

Terry

I don't see, where x vs xst changes anything in search /sort, a prefix is a prefix..
Karl

Wolfgang,
I would not choose a prefix. That makes things indeed more difficult to find in alphabetical completion lists etc.
I think the most important thing is to put the classes it in the right namespace. The class name itself should be meaningful. That's all I think. If you really want to add something to make the name unique, I would go for a suffix.
So you would have something like XSharp.Tools.Windows.Forms.TextBox, or XSharp.Tools.Windows.Forms.TextBoxEx or
XSharp.Tools.Windows.Forms.TextBoxXT

Robert

Hi Robert,

the correct namespace is IMHO obvious, and a meaningful name is very important too - self documenting code is a must.
But since there will be using statements for both namespaces (for example System.Windows.Forms and XSharp.Tools.Windows.Forms) it is important to keep different names - to make it easier for the programmer to understand which controls are effectively used.
Your arguments for a suffix instead of a prefix are very valid! Until now, I have always used prefixes in both VO and X#, but I have to admit that I'm typing the names most of the time, and there a prefix comes handy, at least when it is short.

Thank you very much!

Wolfgang

Hi Karl

A prefix is a prefix - Yes.

It can also help to identify groupings:

Suppose you want to all controls on a global basis. You could search on basis of " Xst" or " x" I agree.
But what if your app had numerous Xml classes etc?

I have also read Roberts reply.

The question seems to be "Do you want to add something to make the name unique"?

Terry

Hi Terry,

The question seems to be "Do you want to add something to make the name unique"?

IMHO this is absolutely necessary. In the other case there would be the need to fully qualify every type, both on declaration and initialization because in most cases both namespaces would be included in the source file.

And unique names make the code also a lot easier to read (and this is one of the things I like very much in xBase languages: that they are easy to read even after years).

Wolfgang

Just wondering: are you considering this for Windows Forms alone, or will it be extended to cover WPF controls.

Terry

Hi Terry,

both, of course. But since I'm working more with WPF, I can add more ( and other) functionality to the WPF classes.

For example, name based binding for WinForms can be accomplished at the Window level, whereas for WPF it has to accomplished at the control level. And since I consider name based binding one of the important features of the VO GUI classes, they will be added to the Tools controls also.

And then will be the possibility to assign a value to a control (not only a text), and when you retrieve it later it will be the same type.

What I'm missing at the moment is a picture feature for both WinForms and WPF edit control.

Wolfgang

Have you considered different prefixes/suffixes for the two namespaces?

Xst Forms
Xctl WPF

It could be users want access to both in their programs.
Just a quick thought - sorry if it's nonsense. Haven't got anything active in XSharp.

Terry

Hi Terry,

no, I have not considered that.

I don't think both will be used on the same form, as it needs some special adjustments to use WinForms controls on WPF forms and viceversa.

But if here more people asks for a differentiation, it can be done.

Wolfgang

Hello,

since I don't think other comments will come in: these are the conclusions:

the classes will have a postfix (Robert's argument are valid - and when using a prefix that starts with "x" theses classes will be at the bottom of the lists), and the postfix will be "xt", so we will have for example a class

Wolfgang

P.S. "xt" could not be mean only "XSharp Tools", but also "extra" <g>

Hi Wolfgang,

I prefer a prefix and a lot of other vendors do the same, for example in the Infragistics Control Suite lots of the class begin with Xam like XamComboEditor.

Regards
Meinhard

Hi Meinhard,

thank you very much for your comment!

So until now Robert is the only one suggesting a postfix.... Maybe I have to rethink about this, and change to a Xst prefix.
It may have some advantages to respect/copy rules all other component vendors are applying.

Wolfgang

Hi Wolfgang

I have been reluctant to comment further on this topic for the simple reason that I do not have any up to date experience of using XSharp, Vulcan, of VO.

In view of Meinhard's comment I'd just like to make a couple of points.

The whole reason for namespaces is to group together classes so they can be spread around an assembly without fear of naming conflicts. Namespace-Classname is concatenated by the compiler.

By using the same control class names for different classes you are breaking this separation.

You may have a very valid reason for doing this, I don't know.

But as a general rule I would not choose to do this.

Using different class name prefixes in different namespaces would satisfy Robert's arguments and allow for Meinhard's preferences.

One further point: Although it may be easy for humans to distinguish between controls having the same name it introduces ambiguity which would add to complexity should some future software tooling be introduced which needed these classes.

Terry

Hi Terry,

By using the same control class names for different classes you are breaking this separation.

No, there must be a misunderstanding.

Code should be self-documenting, so a Button class must be recognizable by its name, and it is a nonsense to have a System.Windows.Forms.Button and a XSharp.Tools.Windows.Forms.Button, because no one will always write the full name, and should not be forced to so.
Therefore the toolkit class will be XSharp.Tools.Windows.Forms.xstButton, so the programmer can write
Wolfgang

Wolfgang,
I see no convenient way to search by postfix, while the absolute position in an ordered list poses no problem, given an incremental search:)

Yes - comments are clearly at cross purposes.


Can't put my finger on why at the moment.


Terry