Transforms: CONVERT_NAME needs more work...

[Paolo F Cantoni]

I've been playing around with Transforms - which, in theory, should be extremely powerful.

One of the biggest issues in transformations is name control...

The Sparxians have recognised this.  Here is an extract from the Help:

Different target platforms may use different naming conventions, as a result you may not want to directly copy the names of your elements directly into the transformed models. To facilitate this need EA's transformation templates provide a CONVERT_NAME function macro.

CONVERT_NAME(<originalName>, <originalFormat>, <targetFormat>)  

Will convert <originalName>, which is assumed to be in <orginalFormat> to <targetFormat>.  

The supported formats are:

• Camel Case: New words start with a capitalised letter. The first letter of the first word is lower case.  
• Pascal Case: Same as camel case but the first letter of the first word is upper case.  
• Spaced: Words are separated by spaces.  
• Underscored: Words are separated by underscores and assumed to be lower case.

Note: Acronyms are not supported when converting from camel case or pascal case.  

Unfortunately this isn't enough control... :(
What we aren't told is that spaced and underscored format is lowercase ONLY! ???

So, in the spirit of "Do it right, do it once..." 8), I'm going to canvas suggestions on what extra degrees of control might be required by transformers, before submitting a formal defect report to Sparx.

In a previous application that I developed, I came up with a different model:
Each name had two attributes:

• Separator: Character (including NULL - for no separators)
  
• Case:Upper, Lower, Title(Pascal here), Camel
  

Thus CONVERT_NAME would become:
CONVERT_NAME(<originalName>, <originalSeparator>, <originalCase>, <targetSeparator>, <targetCase>)
This "pattern" allowed pretty generic conversions.

Can anyone suggest a required conversion that wouldn't be handled by this?

Also, we had a method that analysed a given name and returned the values of the two parameters, so you could check the original name was correctly specified.  (I can provide details if interested...)

Thoughts anyone?

Cheerz,
Paolo

[thomaskilian]

This is one step too far, but I suggest it anyway: In Rose it is possible to adorn almost anything with add-ins written either in the internal Basic dialect or located in a DLL. Thus I would have expected some hook to let the user write a transformation that is passed the string and which returns whatever is desired. I don't know whether Sparx is thinking of such kind of extensibility but this would convert EA into a real power tool.

Of course: one or two steps too far

[Paolo F Cantoni]

This is one step too far, but I suggest it anyway: In Rose it is possible to adorn almost anything with add-ins written either in the internal Basic dialect or located in a DLL. Thus I would have expected some hook to let the user write a transformation that is passed the string and which returns whatever is desired. I don't know whether Sparx is thinking of such kind of extensibility but this would convert EA into a real power tool.

Of course: one or two steps too far

Thomas, this is exactly what I mean about "do it right, do it once!"  Like you, I had considered this, but I wanted to get feedback first before moving on to this...

It seems to me we can attempt to Design Once, implement in steps...  You suggestion is complimentary to the initial proposal.  It seems to me, if we look at what attributes the Name needs to have, we can define boundaries of the add-in's interaction with the conversion process...

For example, one naming standard the proposal I put forward won't handle is my own one!  
Constants are named with <lowercase prefix of 1 to 4 characters><uppercase, underscore separated name>, for example:  gscEMPTY_STRING.
However, the add-in would be a solution,  I see it as returning an enumerated value that would be added to a list composed of various combinations of the Separator and Case attributes.

Using the values of Case and Separator, can people suggest names for the combinations?  For example:
Pascal: Case=Title, Separator=NULL
Java: Case=Camel, Separator=NULL

etc.

Paolo

[Eve]

Hello Guys,

I appreciate where you are coming from.  The existing macro will have to remain, but I can see that it is a bit limited now, even if it does cover the most common naming conventions (possibly when combined with other macros such as REPLACE and TO_UPPER.)

It should be straightforward enough to add a more powerful version of the macro though.

This is one step too far, but I suggest it anyway: In Rose it is possible to adorn almost anything with add-ins written either in the internal Basic dialect or located in a DLL. Thus I would have expected some hook to let the user write a transformation that is passed the string and which returns whatever is desired. I don't know whether Sparx is thinking of such kind of extensibility but this would convert EA into a real power tool.

Of course: one or two steps too far

Wonderful idea....  

It's actually already there.  

When EA 5.0 is no longer in beta you'll be able to look at http://www.sparxsystems.com.au/EAUserGuide/index.html?functionmacros.htm for the EXEC_ADD_IN function call that allows you to do exactly this from any template.  Until then, look it up in your latest beta helpfile.

Simon

[thomaskilian]

You beat me, Simon