Alias and Name Display

[pneutam]

WIBNIF a class' alias and name could be displayed in class diagrams, rather than just the alias if defined. For example, {Alias}({Name})  could be used if an alias is defined, otherwise {Name}.

I am particularly interested in this for data modelling (as the alias and the name are useful to know at a glance).

[mikewhit]

How did you decide that the Alias is the 'principal' name ?

Not having used this feature, I would have thought the Alias should be in brackets, as an alternative to the 'real' name - but correct me on this !

[thomaskilian]

YIWBNFY (Yes, it would be nice for you) but I guess there are other things with more importance  

[pneutam]

If I didn't make it clear, I was suggesting an option to display this format (just like there is one now to either show the alias if available or just the name).

Mike, my interest in this feature is because we use aliases for tables within our code (not within the DBMS). A generalisation of my request is the display of project-relevant properties on class diagrams to aid communication, as the existing feature using the alias if defined, does. I'm not really fussed which one is in brackets, or indeed the format in general - I just bracketted the name under the assumption that you may often use the alias, but still may need to know the name.

Thomas, the WIBNIF acronym implies a low priority. I encourage our customers to give such suggestions as it helps us to see how our products are being used and how they can be improved. IMO, your response discourages such discussion and defeats the purpose of this forum. I would suggest you either clarify the objective of the request (as Mike has done) or, if you understand it but don't agree, state so simply, if at all. After all, if you don't like an option, you don't have to use it  

Cheers

[sargasso]

I think Thomas was commenting more on the acronym - I must admit I didn't get it until his tongue in cheek reply.
regards
Bruce

[mikewhit]

It's OK, he did the same to me elsewhere: "if no one else wants it, it can't be useful", but I sorted him! ;-)

It does oblige us to check whether our requests are for the greater good, or some minor stylistic quirk - which is worthwhile.

[thomaskilian]

Hi all,
probably you are right and I should stop commenting on the worth of a request. It's just that too many small request which of course have worth for a single user will a) delay development of important things (like the desparately missed multi select) and b) clutter up a good product with tons of error prone features (I have to admit that I don't like MS Word for all the useless features - in 90% it is just used as type writer). I'll stick back and recall another request   http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=general;action=display;num=1077009102;start=17#17 especially the voting mechanism.

[pneutam]

A voting mechanism might be useful.

Thomas, I think its okay to say that a feature isn't useful for you (just like a vote), but I think it's too hasty to conclude that it isn't useful to anyone else in 47 minutes!

Sure too many features can be implemented, but they still should be recorded if deemed appropriate (taking into account sheer numbers). A single, elegant feature may satisfy many small requests, though they seem unrelated.

For example, flexibility may be desired for class display, for communication, not style. The larger number of options could be handled by the interface, eg a hierarchical options dialog.

Well, that's my 2¢

[CJ]

G'day folks,

Some kind of voting mechanism would be a great idea.

How's about letting us indicate, in our profile, our top three requests from some list?

Make that list available in the same way as the list of Members is available.  Some link to a list that show all requests and, for each request, the number of members that have indicated interest in that request.