Using a "-" in a Class or Method Name

In my reading about OO stuff the predominant naming convention used for OO work is CamelCase - ThisIsAClassName:MethodName(). I can understand this convention being adopted in that non-ABL languages don't support putting a "-" in a class or method name.
What I'm wondering is -what the implications are of naming classes and methods in a typical PSC IP/ SP API form - like this-is-a-class-name:method-name().

I think it's a simple naming convention: in ABL you shouldn't see any problems with using this style. There are more restrictions on names in classes/methods than procedures (eg. can't start with an underscore) but other than that you should be fine.    

-- peter

What about what happens when one wants to inherit from a PSC internal class - then one has a mix of camel-case and "-" delimited naming conventions going on in their class.

If one wanted to over-ride an existing PSC class CamelCase method in a derived class that used "-" delimited class & method names, then you'd have a class with a mix of "-" and camel-case names in them, would you not?

So, it would almost seem that if one wants to use PSC derived classes in their code and not have any cause for confusion between "internal" and PSC classes, one would have to use a camel case naming structure.

timk519 wrote:
What about what happens when one wants to inherit from a PSC internal class - then one has a mix of camel-case and "-" delimited naming conventions going on in their class.
If one wanted to over-ride an existing PSC class CamelCase method in a derived class that used "-" delimited class & method names, then you'd have a class with a mix of "-" and camel-case names in them, would you not?
So, it would almost seem that if one wants to use PSC derived classes in their code and not have any cause for confusion between "internal" and PSC classes, one would have to use a camel case naming structure.

True - you can't properly override without the names matching exactly: I (mis)read your question to be a technical/ability one, rather than a best practise or convention one.

You could still use your dashed convention, but you'd have to wrap the ancestor method. And since unfortunately the ABL doesn't allow hiding (ie making a PUBLIC member a PROTECTED one in a derived class), you'll have to construct your object by composition rather than inheritance.

So instead of

class Application-Error inherits P.L.AppError
   method Get-Message(...)
   /* implicit via inheritance */
   method GetMessage(...)
end class.

you'd need to do something along the lines of

class Application-Error:
   def private var moPLAppError as P.L.AppError.
  constructor Application-Error(poError as P.L.AppError).
      moPLAppError = poError.
   method Get-Message(pi);
     return moPLAppError:GetMessage(pi).
   end method.
end class.
 

-- peter

If you plan on using GUI for .NET with these dashed class names then you will run into problems.  .NET will reject them as having illegal names.  Use underscores to be safe, or just use camel case.

Thanks for the comments everyone - these are the kinds of concerns I wanedt to avoid when picking a naming convention.

While the ABL use of dash started early and so one can excuse them because the standards weren't established yet, in retrospect the use of dash in ABL was a really unfortunate choice.  Yes, one can get away with it in a pure ABL environment, but the minute one starts dealing with anything outside of ABL one has to go through hoops or make exceptions.  I long ago decided that it was better to just forget dashes altogether.  That way I would be consistent and not find myself having to rework something when needs changed in the future.

And, hey, upper case keywords is so 1960s!  We aren't using punch cards any more!

I LIKE THE 60's.

Don't you know the 60's and 70's are now back in fashion ?

On 6 April 2011 18:46, Thomas Mercer-Hursh

jmls wrote:
I LIKE THE 60's.
Don't you know the 60's and 70's are now back in fashion ?
On 6 April 2011 18:46, Thomas Mercer-Hursh

Um, that's so 2000's of you ... the fricken' EIGHTIES are back now (and  I officially feel old)

80's music, yes. 70's dresses are all the rage.

Not that I wear dresses. I just admire and like them.

On the ladies.

I suppose that you are going to tell me that you use the 029 Keypunch version of OpenEdge Architect?

And your code generator doesn't product files ... it produces tab cards?

often feels like it. When my whole program collapses around me and I

have to put it all back together again in the right order ...

On 6 April 2011 22:24, Thomas Mercer-Hursh

One of the expected benefits of good OO design is that systems should not be so fragile ...

Oh, and the code generator now has templates, custom builder classes,

directives, properties and includes

Would love to show you, but your email is borked

where's the fun in that ?

On 6 April 2011 22:40, Thomas Mercer-Hursh